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