Is Hibernate session disconnection supported

[aaime]

I've searched for the answer for this question in the documentation and in the forums, without finding an answer. Does Spring support the Hibernate session disconnection feature? See http://www.hibernate.org/hib_docs/re...-disconnection
for details about session disconnection.

[cyboc]

Have you looked at Rod's and Juergen's latest book "J2EE Development without EJB"? There is some example code on page 306 that shows you how to disconnect and reconnect using Spring's HibernateTemplate class. The program flow was basically this:

on server:
- create a HibernateTemplate
- do a HibernateTemplate.find() to get some records as objects.
- return objects to client (or web controller)

on client:
- iterate objects, setting some attribute values via setters (e.g. customer.setFirstName("George"))
- send objects back to server

on server:
- create a HibernateTemplate
- iterate objects, calling HibernateTemplate.update(myObject) for each object.

I hope this answers your question. By the way, if you don't yet have the book, you should get it. It is well worth the price because it goes well beyond the Spring Reference in terms of explaining concepts. (No, I don't work for Rod and I'm not getting paid any money for this endorsement. I just think the book is great!)

Cheers,
Cyboc

[aaime]

Sorry but what you are reffering to are "detached objects", nor disconnected sessions.

It's not the same thing, and, both performance and behaviour wise, disconnected sessions should be much better, at least if you are using things like collection elements garbase collection and the like, besides the fact that with disconnected sessions you don't need to re-attach objects to the session. Please have a look at the hibernate documentation in the page I was referring to with my link.

Since no one else responded, I guess I have my answer: Spring does not support that session management mode (and apparently no-one here really knows what it is...)

[Colin Sampaleanu]

I've searched for the answer for this question in the documentation and in the forums, without finding an answer. Does Spring support the Hibernate session disconnection feature? See http://www.hibernate.org/hib_docs/re...-disconnection
for details about session disconnection.

Session disconnection relies on the user maintaining and managing, long-term, a Hibernate Session, deciding when and if it should actually be created, 'connected', disconnected, closed, etc. The whole point of Spring's Hibernate integration approach is that you shouldn't have to manage the Session lifecycle.

So no, there's no explicit support in Spring of Session disconnection...

[aaime]

Thank you for the clarification.
Too bad, since session disconnection is the most performant and reliable method of managing the sessions according to "Hibernate in action". On the other side, I guess I see the problem: providing the user with means to manage the session this way would make the code non transparent, that is, hibernate dependent without hope of changing it back to a lower level approach (such as JDBC)...

[Juergen Hoeller]

Too bad, since session disconnection is the most performant and reliable method of managing the sessions according to "Hibernate in action". On the other side, I guess I see the problem: providing the user with means to manage the session this way would make the code non transparent, that is, hibernate dependent without hope of changing it back to a lower level approach (such as JDBC)...

Indeed, session disconnection requires you to put a Hibernate Session into the HttpSession: This is arguably not too desirable for a variety of reasons, among those holding the entire first-level cache in memory (or in a persistent HttpSession store) - spanning multiple requests! A further one is that you might see stale data, and of course that someone needs to manage the lifecycle of that HttpSession-held Hibernate Session.

I know that Gavin favors disconnected Sessions, but I guess I have a different view in that respect. I simply do not consider it worth the effort for most use cases. And while session disconnection can give you better performance (first-level cache with longer span), it does waste memory, and I don't see why it should be more reliable (quite on the contrary, it might hold stale data and carry those into a new transaction).

The main benefit of transaction-scoped Hibernate Sessions (Spring's default model) is that the user does not have to care about it: Session management will be completely implicit. A side benefit is that facade and workflow code does not have to work with tool-specific persistence API, but rather just applies generic transaction demarcation. This allows to switch the persistence layer (probably rather to JDO than to JDBC).

Of course, nothing stops you from using disconnected Hibernate Sessions in a Spring-based application. You'll just need to do the Session lifecycle management yourself, but you can still pass the SessionFactory to application beans via IoC etc. You could even combine Spring's HibernateTransactionManager with this, if you leverage pre-binding of Sessions to the thread (like OpenSessionInViewFilter does).

Juergen

[aaime]

Thank for the explaination. For the web application point of view, it makes perfect sense.
But I don't develop web apps, I usually develop rich clients for a limited number of users. Those clients are usually quite complex compared to a web app, and they also load quite a lot of data (a master/detail form with a 100 rows table is not uncommon).
My problem is that if I use disconnected sessions hibernate knows which of the 100 rows changed, and can perform a reasonable query, if I use detached objects, it cannot, so it has to save them all.
In those cases it seems that trying to design the application in an object oriented way using an or-mapper gets more in the way than it benefits, compared to an approach that directly bounds recordsets to a table...

[Juergen Hoeller]

My problem is that if I use disconnected sessions hibernate knows which of the 100 rows changed, and can perform a reasonable query, if I use detached objects, it cannot, so it has to save them all.

That's true if you're returning the list as primary result. OTOH, if you have a primary domain object that contains the list as associations, you'll get a Hibernate collection implementation that tracks changes, both in the list structure and in the container objects. If you then update the primary domain object in the course of a new Session, Hibernate will just issue update statements for actually changed objects. Of course, such modelling might not be appropriate for your scenario....

Don't get me wrong, I do the value of the disconnected Session pattern. I just recommend to avoid it if you can, respectively if you don't get much benefit out of it. However, if your scenario cries out for a disconnected Session, then use it! As I indicated, Spring does not get in your way here: Simply manage your Session instances in application code, possibly getting them from a Spring-provided SessionFactory. You just won't be able to leverage Spring's implicit Session management.

Juergen

[cnelson]

There is another reason to use disconnected sessions: Hibernate's optimistic-lock="all|dirty" feature works with disconnected sessions, but not across new sessions. This means when using spring's default [hibernate] session management, you must use hibernate's "version" mode which requires an additional colum in the database if hibernate is going to be able to detect concurrent modification / stale objects.

I'm currently working on a project where I don't have the freedom to add such a version column. Some people feel very strongly about not polluting their db schemas with columns only to use an O/R tool.

I will look into managing the [hibernate] session lifecycle myself. It's a shame however, because it's so convenient, easy, and clean letting spring handle it as it does.

An interesting thread regarding optimistic-lock over at hibernate:
http://forum.hibernate.org/viewtopic...optimisticlock

Cheers,
Christian

[Loumeister]

I'm currently working on a project where I don't have the freedom to add such a version column. Some people feel very strongly about not polluting their db schemas with columns only to use an O/R tool.

There's other solutions as well. You could use timestamp field, although not as fullproof as a version field. Most DBAs use audit fields that you could piggyback on, but it's not certainly not an unusual request for using a version field. DBAs! :roll:

Lou