Yes, that's what I am doing. I will then store the objects in the 
session and later add support for storing them in a temp table if needded.

In case the objects are to be saved in the database, what would be the 
best approach? I the same table as the actual object (needs one more 
field to indicate if it is an original clone or an actual object)? Or in 
a separate table (needs to double the number of tables)?

Pierre-Yves

Igor Vaynberg a écrit :
> if you keep a clone of the object before the change in your session 
> (which sounds like you do) then there wont be any issues. you have all 3 
> states needed to merge correctly.
> 
> -Igor
> 
> 
> On 9/13/06, *Pierre-Yves Saumont* <[EMAIL PROTECTED] <mailto:[EMAIL 
> PROTECTED]>> 
> wrote:
> 
>     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]> <mailto:[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>
>      >    
>     <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>
>      >     <mailto: 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>
>      >     <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
>     <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