ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shannon, Bryan" <BShan...@Tribune.com>
Subject RE: Poll: comparing old and new beans before persisting
Date Tue, 29 Apr 2008 13:50:23 GMT
Actually, I send in just the old and new beans;  Locking can either be
pessimistic or optimistic and is at the "record" level.  Since the utils
are all callback/template based, you could potentially check the value
for the list in the database in your callback method if you need to.

I have found that in many of my data entry cases, optimistic locking at
the record level is fine; a simple ("before you save, make sure that the
record in the database doesn't have a more recent timestamp than the one
you loaded as a last update timestamp")  

In my specific case, we then let the user decide whether or not to save
their changes anyway, (possibly) overwriting the other user's changes.
[that ability is permission based].  (again, the overwrite would only
meddle with the other user's changes if they changed the exact same
collections as we did, since the util class only persists things that
are different.)

The actual comparison for the list properties goes a little like this
(just a rough outline):
If there is an object in oldList, but not in newList, then it is an
If there is an object in newList, but not in oldList, then it is a
If there is an object in oldList and newList that have the same PK but
not the same content, then it is an update.  (the way it actually
determines this is customizable).

Optionally, reordering fields in a list between old an new can
optionally be considered an "update", since there are cases when our
join tables have something like:

Person_id	favorite_food_id	sequence
---------	----------------	--------
13423		42			1
13423		54			2


-----Original Message-----
From: Chris Marshall [mailto:chris@campsbayterrace.com] 
Sent: Tuesday, April 29, 2008 7:00 AM
To: user-java@ibatis.apache.org
Subject: Re: Poll: comparing old and new beans before persisting

Hi Bryan,
If I understand you correctly you implement a form of field level
optimistic locking using three versions of a bean - the original bean,
the modified bean, and the currently persisted bean (which may have been
changed by others since the original bean was read). By comparing the
properties of each you update only those properties that have changed,
presumably only if they have not been changed by others in the meantime.
Is this correct?
Regards Chris

View raw message