I eventually implemented something very close to what you describe. 
Basically it is a sort of optimistic locking with field merging so that 
update fails only for those fields that are found different at update 
time than at read time. In such case, fields that can be updated are and 
those that can't are left unchanged. The form is redisplayed so the user 
can see the two versions. If he saves a second time, all fields are updated.

However, to achieve this, I need to implement pessimistic locking for a 
short time, between the time the form is redisplayed and the time the 
user saves again or cancel. (Pessimistic locking is also implemented 
between a delete request and its confirmation or cancellation.)

The problem is that the user can make a third choice and go to have a 
coffe break. So, the lock that the user (in fact the session) has 
acquire will expire after some configurable time. It works by writing 
the session id, the lock time and the maximum delay into the database. 
That way, if another user comes, he can see if there is a lock and if 
this lock is active, and act accordingly. This is supposed to solve the 
problem of the user not releasing a lock.

There is still a problem: in the optimistic/merge scenario, I must have 
a copy of the field values at read time to compare with the modified 
fields and the actual fields. For this, I keep a reference to the 
hibernate object. The modified fields are in a value object.

Not holding a reference to the original object would not be relevant if 
I would still hold a reference to the value object. It makes little 
sense to throw one away and keep the other. But there is no hibernate 
related problem, since the object is never used to persist or merge the 
data.

Now, it could be possible to keep only the ids of the objects. For this, 
I would have to store the two objects in the database. But I do not 
think this would be rewarding. I would need to create special tables for 
this, write the two objects, read them, and eventually delete them. I 
prefer to have small objects (in case of big entities, just break them 
in smaller parts) and store them for the duration of the pseudo 
transaction. At worst, they will be thrown away when the session expires 
and the locks in the database will have themsevles expired much longer 
before.

The real question is "which potential problem is hidden in this scenario 
and will suddenly jump out when the app will be in production ? :-("

Pierre-Yves

Johan Compagner a écrit :
> you really shouldn't lock objects over request..
> Because you don't controll anything. He can close the browser or go away
> In a swing app where you have a connection to you can at least do 
> something about it
> (and show that to the user that he looses it and take it again on a 
> focus of a field)
> 
> But long transactions or locks over request is in my eyes bad praktisch 
> that shouldn't be done in a webapp.
> 
> Maybe with full use of ajax you can get to the behaviour a bit that a 
> fat client would have..
> 
> But i prefer other way. Just let it change it and if it did change (does 
> that really happen a lot? i can't believe that)
> then report that first back to the user that a save couldn't happen 
> because another person did change it already
> and do show those changes (try to merge it)
> 
> johan
> 
> 
> On 9/12/06, *Pierre-Yves Saumont* <[EMAIL PROTECTED] <mailto:[EMAIL 
> PROTECTED]>> 
> wrote:
> 
>     Hi,
> 
>     Is there a Wicket (ie really smart) way to detext when the user switch
>     to another page?
> 
>     The use case is to release locks that a user might have put on database
>     records with pessimistic locking when the user switch to another page.
> 
>     Pierre-Yves
> 
> 
>     -------------------------------------------------------------------------
> 
>     Using Tomcat but need to do more? Need to support web services,
>     security?
>     Get stuff done quickly with pre-integrated technology to make your
>     job easier
>     Download IBM WebSphere Application Server v.1.0.1 based on Apache
>     Geronimo
>     http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>     <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
>     _______________________________________________
>     Wicket-user mailing list
>     Wicket-user@lists.sourceforge.net
>     <mailto:Wicket-user@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/wicket-user
>     <https://lists.sourceforge.net/lists/listinfo/wicket-user>
> 
> 


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to