Maintaing State while using HttpInvoker

[dlkpochtaws]

are you absolutely sure that you need to maintain state on the server? If you post your use case perhaps we can suggest an alternative implementation that uses the existing (stateless) remoting support.

Hi Ollie.
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
E.g.
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

[oliverhutchison]

The second approach (to fetch edited object from DB) has obvious performace penalty

does it? Given that you already loaded the object in step 1 it's extremely likely that it's still in the Hibernate cache (assuming your using a cache). Also how many updates does your application actual handle? Is the small overhead of doing a DB fetch really significant? If it is, my gut feeling would be that the overhead of placing all of the loaded objects into the session would be even greater.

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.

If you take advantage of Hibernates optimistic concurrency support this is not an issue. How do you prevent/handle multiple concurrent updates with your statefull approach?

I'm know there are some valid situations where maintaining state on the server does make sense (transferring chunked data springs to mind) but most of the time you shouldn't need this feature.

Ollie

[dlkpochtaws]

The second approach (to fetch edited object from DB) has obvious performace penalty

does it? Given that you already loaded the object in step 1 it's extremely likely that it's still in the Hibernate cache (assuming your using a cache).
Is the small overhead of doing a DB fetch really significant?

Do you mean transaction-level (first-level) cache or second level cache? Please note, we've closed the database transaction and discarded hibernate session after step 2) - so we don't have first-level cache. And since edited BOs are actively edited, they are not cached in second-level cache.
And the overhead to fetch DB for BO is significant in my system - due to some reasons discussed BOs are quite expensive to load from DB - they are spead accross some SQL tables, so there are several roundtrips to DB when we fetch each object.

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.

If you take advantage of Hibernates optimistic concurrency support this is not an issue.

The approach I use in my system is descibed in Section 8.2 of the book "Hibernate in Action". Your particular approach is closest to the section 8.2.2 in this book, named "Doing it the hard way" :-). Let me cite some paragraph from it:
"There is one problem with this notion: The user already used the possibly stale data to arrive at the decision to approve! Reloading the Item in the second request is useless, since the reloaded state will not be used for anything —at least, it can’t be used in deciding whether the auction should be approved, which is the important thing."

Yes I agree we can still use automatic Hibernate's version checking capability, but "The user already used the possibly stale data to arrive at the decision to approve".
And this book advises (Section 8.2.3) using detached object support of Hibernate, which is my preferred approach.

WBR, Dmitry.

[oliverhutchison]

And since edited BOs are actively edited, they are not cached in second-level cache.

Can you please explain this? Why are you BO not cached in the second level cache? Given that you've said that they are very expensive to load this sound like a bad idea.

The approach I use in my system is descibed in Section 8.2 of the book "Hibernate in Action". Your particular approach is closest to the section 8.2.2 in this book, named "Doing it the hard way"

I've don't have a copy of HiA so I can't have a look at sections 8.2 and 8.2.2 but I can certainly say that the approach I suggested is not "the hard way" and is in fact "best practice". Especially when you are working with the detached object support. The following is from the Hibernate manual:

We very strongly recommend that you use version/timestamp columns for optimistic locking with Hibernate. This is the optimal strategy with respect to performance and is the only strategy that correctly handles modifications made to detached instances (ie. when Session.update() is used)

Ollie

[dlkpochtaws]

And since edited BOs are actively edited, they are not cached in second-level cache.

Can you please explain this? Why are you BO not cached in the second level cache? Given that you've said that they are very expensive to load this sound like a bad idea.

May be I shall cache those BOs, but I prefer caching only reference (read-only) data. May be it worths trying caching these BOs, since they are expensive to load, I'll think it over. Although authors of HiA claim: "Bad candidates for second-level caching are: Data that is updated often". Because ot that I don't chache them.

I can certainly say that the approach I suggested is not "the hard way" and is in fact "best practice". Especially when you are working with the detached object support. The following is from the Hibernate manual:

Yes I do agree that Hibernate's ability to automate handling versions column is very useful. But the "hard way" also has other upleasant feature - you fetch data which is possible inconsistent that user has seen.
And please note words in your quote "strategy that correctly handles modifications made to detached instances" - detached instance means some kind of server-side state in my scenario.

WBR, Dmitry