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]> 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]>>
> 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

-------------------------------------------------------------------------
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