Subject | Re: [IBO] ib_query.isrowlocked does not work |
---|---|
Author | Helen Borrie |
Post date | 2006-09-17T13:50:02Z |
At 09:49 PM 17/09/2006, you wrote:
Firebird is an optimistic locking system. So any record that has an
update or delete posted to the database either succeeds (and gets
locked) or fails (and causes an exception). The lock stays until the
transaction that posted the update is committed or rolled back.
We can force a pre-emptive lock in one of two ways:
1. Post a dummy update (that's an update that doesn't change
anything) - this is what IBO does if you set PessimisticLocking true
and put a record in to Edit mode.
2. (In Fb 1.5 and higher) request the record "FOR UPDATE WITH LOCK".
You will get an exception if you try to do either 1) or 2) and the
requested record is already locked by another transaction. There is
no distinction between a "pessimistic" lock and any other kind of
lock - a lock is a lock.
Helen
>Hellen,Ummm.....you don't seem to understand how concurrency works.
>thanks for your replay.
>So the bottom line is: The only reliable way to determine a network wide
>(pessimistic) lock on a row is to let it run into the exception and
>react on this.
>Okay, i can manage that in my application.
Firebird is an optimistic locking system. So any record that has an
update or delete posted to the database either succeeds (and gets
locked) or fails (and causes an exception). The lock stays until the
transaction that posted the update is committed or rolled back.
We can force a pre-emptive lock in one of two ways:
1. Post a dummy update (that's an update that doesn't change
anything) - this is what IBO does if you set PessimisticLocking true
and put a record in to Edit mode.
2. (In Fb 1.5 and higher) request the record "FOR UPDATE WITH LOCK".
You will get an exception if you try to do either 1) or 2) and the
requested record is already locked by another transaction. There is
no distinction between a "pessimistic" lock and any other kind of
lock - a lock is a lock.
Helen