Hi Rickard,
>it seems that your implementation of a lock needs to involve two fields:
>who locked it, and when. The who lets you determine who is allowed to
>unlock it, and the when allows you to "time out" the lock. When you
>check isLocked() you need to not only see if a lock exists, but also the
>age of it. If it has timed out then you may remove or replace it.
This is a description of what I believe is known as "pessimistic locking".
We've been implementing this here, and the amount of headaches it can give
you is far from funny. Furthermore, there's scope for dirty reads using this
technique. If you're doing this, you'll have to fire 2 queries on the
database - a select to get the record (and check whether the record is
locked), and a lock() method, which will update the lock-related (i'll call
it soft locking) fields in the database with user ID and timestamp.
assume that user A queries for a record, and gets a record. in the meantime,
user B queries for the same record, locks it, updates it, and releases the
lock. now user A (who has no idea of what user B has done) locks, updates
and unlocks the record. a Bad Thing has happened - user A modified data
based on information he had on his screen, which did not reflect the
underlying row in the database.
the solution is to build in some "optimistic locking" to complement the soft
locking technique. user A should check the "last update on" timestamp of the
record before doing an update. if it doesn't match that in the record he has
onscreen, the update/lock fails.
hth... ashwin
----------------------------------------------------------------------------
-----------------
> Unix is an operating system, Windows is a Nintendo with keyboard
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
