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 > Wicketfirstname.lastname@example.org > <mailto:Wicketemail@example.com> > 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 Wicketfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/wicket-user