I couldn't agree more with Wendy. But, as with more things, it comes
down to your application.
I work at a large financial institution, so I deal with these types of
situations quite a bit. It all depends on what is being edited.
If we are talking about something like, say, a fund load fee reference
table, it might be appropriate to use an pessimistic locking mechanism
where once one user obtains a lock on a record, no one else can edit it
until their changes have been committed (whether you allow reads or not
is still a question). What I've done in these instances is (a) tied the
unlocking code to a SessionListener so that if the user walks away, I
unlock any record they had locked when their session expires (typically
no more than 20 minutes). Their changes are lost of course, and (b)
clear all record locks at app startup, in case it goes down and is
restarted (which is more interesting than you might think since we're
hosted in a clustered environment, but that's a whole other ball of wax!)
If it's more of a transactional system, or a system where a record can't
be locked for any real length of time, i.e., maybe a customer record
that can't truly be locked for more than a few seconds, there are plenty
of games to be played, but they all generally come down to some sort of
timestamp and logic to work with it. I also generally have some sort of
background/periodic process to check for stale locks and get rid of
them. The details of this are usually app-specific and so there
probably isn't any general-purpose answer to give.
As Wendy said though, locking is usually best handled in the database
itself. The one big exception is something like a wizard interface
where the lock has to persist across multiple requests for a given
session. If you don't have such a requirement though, if a record is a
per-request thing, I for one would definitely council against doing
anything but locking in the RDBMS itself, and I would generally use a
pessimistic locking scheme, with the understanding that this directly
impacts scalability. Again, it comes down to what the app is and has to
do though, that might be acceptable, or it might not be.
Frank
Wendy Smoak wrote:
On 11/1/05, Murray Collingwood <[EMAIL PROTECTED]> wrote:
The scenario is very simple:
1. User A clicks an "edit" option to edit a record.
2. While user A is editing the record user B clicks the same "edit" option
3. Both users are now editing the same record (or so they think)
4. User A clicks "save" and the record is updated and displays the changes
made by
user A - user A is happy
5. User B clicks "save" and these changes overwirte the changes made by
user A,
however user B doesn't know this and the changes made by user B appear.
Trying to hold real database-level record locks from a web interface is just
asking for trouble. The user wanders away, the connection drops...
meanwhile, no one else can get to that record.
I'm in a situation where I have to work around a telnet app that thinks it
is the only thing accessing the database. I calculate a checksum when I read
a record, and then check again before writing the record back. If the
checksum has changed, then someone else touched the record (most likely from
the telnet interface) and the web-user loses.
This happens in the data access layer, Struts doesn't know anything about it
other than being configured to handle a RecordModifiedException.
--
Wendy
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
