On Oct 19, Ingo Bruell quoth:
> Hi Dan,
>
> > There is no automatic time-out mechanism in J2EE that you could
> > adapt for use in a pessimistic locking scheme. One possibility
> > might be to store leasing information along with check-out
> > information. When a conflicting client tries to obtain a lock, the
> > existing lease could be examined for validity.
>
> But what happens, If the client crashes, how the stored leasing information
> would be set back ?
For another perspective: In a previous project I had to deal with 'big'
records that were checked out for a long time for editing and we needed to
prevent others from checking out the same record and wasting their time
doing edits that wouldn't be committed (multimedia). Therefore we
instituted pessimistic locking on a per-user basis. These locks prevented
another person from checking out the same record for editing until the
original person put their new version back in.
We then implemented a 'break lock' operation in the client to deal with
'vacation'. The new user was presented with a message like "Bob Jones
locked this record on 2000-10-14 09:30, breaking this lock will invalidate
any work they have done to date. Would you like to break it?" This
allowed a user to explicitly break another users lock on the assumption
that they would have first check with the original lock holder. Fewer
"are you sure?" messages were given if the person breaking the lock was
the original holder of the lock.
C=)
--------------------------------------------------------------------------
The fact that no one understands you doesn't mean you're an artist.
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// TechnoCage Inc.
--------------------------------------------------------------------------
Oh no! Space monkeys are attacking! -- eddie izzard
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
