On 5/22/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Ok, I understand, in the past I also used client-side state saving, but things happening lately showed me that in the end I cant stick with it. Transparent persistence (hibernate) - "application transaction" - to tell only the headlines ;-) require to NOT serialize/deserialze your state (the upcoming conversationTag will help here), thus you can switch to server-side state saving as e.g you cant restore the state if it timed out so client-side ss wont help much.
Yes, it's a tradeoff issue. For intranet applications, I find it's better to use client-side state saving. If I was writing an internet app, I'd probably go back to server-side state saving. Also, I'm using Cayenne instead of Hibernate, and with Cayenne I can store my persistence objects as part of the client-side state when necessary. Most of the time, I keep my persisted/database objects in a committed state between requests. I do keep a cached datacontext (hibernate session) in the container session map, but if it's not found, it'll just be recreated. Persisted objects which are in a non-committed state stay in the request (or page via saveState) scope.
