Subject | Re: [firebird-support] get_lock / release_lock |
---|---|
Author | Kjell Rilbe |
Post date | 2008-07-31T13:05:21Z |
Steve Wiser wrote:
has to select with lock when checking the field. Otherwise you end up
with a race condition:
1. User1: select
2. User2: select
3. U1: OK, no lock!
4. U2: OK, no lock!
5. U1: Update & commit
6. U2: Update & commit, overwriting U1's lock
Now both users think they've got the lock.
With select with lock, user 2 will get an exception at step 2, which is
what we want.
Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64
> Just add a new field to the table called LOCKED_BY_USER or something andIf the intention is to update that field and then commit, then the app
> when a user wants to lock a record you just update the table so it is
> filled in with their user id. Other instances of the program should
> check that field and not allow the user to touch the record if it is not
> null. Of course once the original user is done they need to update the
> table again and null out the field...
has to select with lock when checking the field. Otherwise you end up
with a race condition:
1. User1: select
2. User2: select
3. U1: OK, no lock!
4. U2: OK, no lock!
5. U1: Update & commit
6. U2: Update & commit, overwriting U1's lock
Now both users think they've got the lock.
With select with lock, user 2 will get an exception at step 2, which is
what we want.
Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64