1. Well, here's what would happen. Suppose I want to update a Person object on my EditPerson page. I use the "session" persistence strategy and I just store the id of the person. So, I render the EditPage and it shows a form. I edit some values and I submit my request. Suppose someone beat me to the punch, though. While I was sitting there looking at the data from this Person object and contemplating what their real first name should be, someone else used the edit page to update the exact same Person object. When my request comes in, I'll do a Hibernate query to lookup the Person object (by id) in the database. I'll set some properties on it and commit my changes. Since I got the current values out of the database by querying for the object, my request will work just fine and I will have overwritten the changes the other user has done. If I use the "entity" persistence strategy (my implementation), I will be updating an object that has the old version number in it. Hibernate will throw an exception and I will not be allowed to overwrite the changes the other user has done.
2. If you want to see the squeezer in action. Use a @Hidden component and set the value of it to an object which your squeezer supports. -----Original Message----- From: Andreas Bulling [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Bulling Sent: Saturday, April 22, 2006 9:07 AM To: Tapestry users Subject: Re: tapestry/hibernate sessions & pageBeginRender() | Well, if you just store the id (and entity name) in the session, then you | totally circumvent the automatic optimistic locking capability of Hibernate | (you'd be reading the current version number every time instead of just | attempting to reattach the old object). Well, I have to admit that I don't understand what the optimistic locking feature has to do with the strategy issue :( >From my understanding it should be possible to just store the id to get a smaller session (but more database accesses for sure). And could you please say what your persistence strategy can be used for because I don't understand this either - thanks! | Squeezers aren't used by the client persistence strategy, unfortunately. OK, and when _are_ they used? With @Persist? How can I see them "in action"? ;) Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
