Tye, Tim wrote:
> Your "lock on a row" is not a lock at all. It is a special data value
> defined by you persistent in a specific database column. This becomes a
> question of database design and not one about EJB. I suggest that you use a
> database group to help solve this problem.
>
> -----Original Message-----
> From: ASHWINJM [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 02, 1999 9:50 PM
> To: [EMAIL PROTECTED]
> Subject: Re: releasing the lock-urgent
>
> the difference here is that the database's locking mechanism is *not* being
> used. the problem is one of releasing a lock on a row should a user lock it,
> and log off, ending his session, but leaving the row locked. as a result of
> which we have to resort to mechanisms such as these for timing out a lock.
>
> > -----Original Message-----
> > From: Tye, Tim [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, December 02, 1999 10:19 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: releasing the lock-urgent
> >
> > -----Original Message-----
> > From: ASHWINJM [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, December 02, 1999 7:30 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: releasing the lock-urgent
> >
> > > 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.
> > >
> > This cannot happen in a transactional aware database. The user A queries
> > (Read Only) which tells the database the data can be changed. Then user B
> > queries under transaction control (read-update-commit) and locks the
> > entity.
> > The database must not let any user write data outside of a transaction.
> > Therefore, when user A decides to lock the same entity, the transaction
> > control (read-update-commit) the read will discover that the entity is
> > already locked by B, and A must rollback and not modify the lock.
How to achieve isolation of activities lasting minutes to a few hour is an
interesting and well-known transactional application design problem. As has
already been said, the Isolation property of transactions not suitable for such
long locking solving and it is not a mere database design problem.
The general approach of using soft locks (i.e. fields in tables in the database)
to represent and persist the lock is a good one. However, unless the run-time
environment has a reliable distributed conversational context to inform the
application if the client "vanishes" (which EJB does not have) there is a
problem of deleting the soft locks in error situations. One solution is to
record in the database the time the server application on behalf of Client A
obtained the lock. When the application later needs the lock on behalf of client
B it can tell if the timeout period has expired.
Ian McCallion
===========================================================================
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".
