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.
>
> ==========================================================================
> =
> 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".
===========================================================================
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".
