Re: [Hibernate-devel] Hibernate and Connection Pooling

[Gavin_King/Cirrus%<CI...@ci...>]

To simplify matters just a little bit, think of a Session as a transaction.
Open a Session at the start of a transaction, close it at the end. The
Session retains a JDBC connection for only as long as your transaction.
This is exactly the same as any other common J2EE approach (direct JDBC
from a servlet or session bean, CMP entity bean). J2EE applications are
characterized by short running transactions. Typically applications
retrieve data in one transaction, display it to the user, recieve user
input and then modify data in a second transaction. Hibernate is also meant
to be used in this way.

My *suggested* approach is to use the same kind of architecture recommended
for entity beans. Namely, MVC where V=JSP/XSLT/VTL and C=servlet, Session
bean facade (perhaps command pattern) and then business objects holding
persistent data. Unfortunately, there are numerous well documented problems
with Entity beans. You could instead use Hibernate to persist your business
objects, which could just be vanilla JavaBeans instead of Entity beans. You
may use hibernate-persisted objects in all the ways you can use Entity
beans (and more) except for the fact that they are not, by default,
remoteable (arguably a very good thing).

Or you can use Hibernate to implement BMP entity beans and get support for
concepts like (sub)collections, dependent objects, object graph to a single
row, etc. This will allow a *much* finer grained object model than what is
normally possible when using entity beans.

Whatever approach you use, you should not leave the Session open longer
than you would keep an open JDBC connection when using some other
persistence mechanism.

A future version of Hibernate will extend the support for optimistic
locking (ie. versioned data) to cover the possibility of retrieving
business objects in one transaction (Session), editing them in the UI
layer, sending them back to a new Session and updating the datastore. You
can already do this kind of thing yourself now, using Session.copy() for
the last step, but what you would really like is to be able to update a
whole graph of objects with one call to the Session. Note that this kind of
approach is NOT a very typical J2EE approach. I happen to like this it very
much, even though it increases coupling between application layers.

Sorry if this was badly-written; it is very late here :)

peace

Gavin