Hi Ollie.Originally Posted by oliverhutchison
From my point of view, server-side state is very important when you use Hibernate on the server and you have a remote client.
It simplies things when you do typical load - edit - save Business Object (BO) cycle
1) User requested a BO to be shown in "Edit Dialog" (by Id)
2) Hibernate loads it and closes the database transaction
3) You push loaded instance to the server-side storage
4) You serialize instance to remote client.
5) User edits it, and then send it back to the server.
6) Server looks up the pushed instance in server-side storage and applies deserialized user changes to it
7) Server calls some kind of [Hibernate] Session.save(BO)
Please note, we can't serialize the whole BO instance on step 4), e.g. because of security reasons (current user is not allowed to see all fields in instance) or maybe because the BO is quite big and expensive to serialize (not all fields must be shown in current "Edit Dialog"). Because of that we can't recreate the edited BO in step 6) from deserialized information without server-side storage or additional SQL query to fetch it again from DB. The second approach (to fetch edited object from DB) has obvious performace penalty and has a side effect - this BO may have been changed since step 1), so user's changes will be mixed with other's changes.
IMHO this use case forces us to use some kind of server-side state management, and HttpSession very convenient in a case of HTTP remoting :-)
WBR, Dmitry Kirillov