struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: Record locking
Date Tue, 01 Nov 2005 23:11:17 GMT
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.


Wendy Smoak wrote:
> On 11/1/05, Murray Collingwood <> 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
AIM: fzammetti
Yahoo: fzammetti

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message