| Subject | Re: [IBO] Row edited but not committed - deadlock |
|---|---|
| Author | Geoff Worboys |
| Post date | 2010-04-16T00:33:32Z |
Hi Hércules,
"deadlock" something you've read about and decided you should
do something about it?
If you don't have a specific problem then working with the
defaults until you experience a specific problem is usually the
best way to make progress.
However... I cannot say that I am a fan of TIB_Database. It is
OK for small and simple applications that only ever need a
single transaction... but if you have something that may get
more complicated then you will want to start with TIB_Connection
and a separate TIB_Transaction for each conceptual transaction.
(For example it is likely that each form may have it's own
transaction.)
[[ If you are new to transactions spend some time playing with
the various demo and tutorial applications until you gain some
experience and confidence using transactions. Transactions can
be really really useful but setting AutoCommit to true avoids
many of the benefits. Learning about transactions will help
you design more useful applications. See the transaction
tech-info sheets at: http://www.ibobjects.com/TechInfo.html ]]
If you really want to lock a record when it is edited then
you need to look at the PessimisticLocking property of the
query/cursor you are using. Note that for this to be effective
you will probably have to turn off AutoCommit (in your
TIB_Transaction or TIB_Database), which will mean implementing
your own transaction control (usually a good thing anyway).
While there can be situations in which PessimisticLocking is
useful, to use it throughout your application may lead to
more trouble than it solves.
Note also that "DML Caching" is another way to deal with the
issue of updates coming from multiple users.
http://www.ibobjects.com/TechInfo.html#ti_dmlcaching
HTH
--
Geoff Worboys
Telesis Computing
> Before post a record: how to know if that record was editedie. These are the defaults.
> but not commited in another transaction, on the network?
> In the IB_Database connection:
> - autocommit=true, isolation=tiCommited, recversion=true, lockwait=false
> I'm trying to avoid deadlock!Are you trying to work around a known/specific problem... or is
"deadlock" something you've read about and decided you should
do something about it?
If you don't have a specific problem then working with the
defaults until you experience a specific problem is usually the
best way to make progress.
However... I cannot say that I am a fan of TIB_Database. It is
OK for small and simple applications that only ever need a
single transaction... but if you have something that may get
more complicated then you will want to start with TIB_Connection
and a separate TIB_Transaction for each conceptual transaction.
(For example it is likely that each form may have it's own
transaction.)
[[ If you are new to transactions spend some time playing with
the various demo and tutorial applications until you gain some
experience and confidence using transactions. Transactions can
be really really useful but setting AutoCommit to true avoids
many of the benefits. Learning about transactions will help
you design more useful applications. See the transaction
tech-info sheets at: http://www.ibobjects.com/TechInfo.html ]]
If you really want to lock a record when it is edited then
you need to look at the PessimisticLocking property of the
query/cursor you are using. Note that for this to be effective
you will probably have to turn off AutoCommit (in your
TIB_Transaction or TIB_Database), which will mean implementing
your own transaction control (usually a good thing anyway).
While there can be situations in which PessimisticLocking is
useful, to use it throughout your application may lead to
more trouble than it solves.
Note also that "DML Caching" is another way to deal with the
issue of updates coming from multiple users.
http://www.ibobjects.com/TechInfo.html#ti_dmlcaching
HTH
--
Geoff Worboys
Telesis Computing