[Springframework-developer] Hibernate setup in an ApplicationContext

[<jue...@we...>]

After the general DataSource ones, some notes on Hibernate setup:

For the non-JCA case, I would not access Hibernate's SessionFactory via =
JNDI (natural with JCA), as you'll have to fight with binding to the =
container's JNDI tree then. For example, Tomcat has a read-only JNDI =
tree - no custom binding there. Spring's LocalSessionFactoryBean allows =
for convenient setup of non-JNDI session factories, giving bean =
references to HibernateTransactionManager, HibernateTemplate, or custom =
beans (just like a JndiObjectFactoryBean would too).

Hibernate supports a number of connection providers. As it doesn't =
export the DataSource it uses, you'll have to use a JNDI one to be able =
to share the DataSource. In a Spring application, you can define a =
JndiObjectFactoryBean that takes the DataSource from the same JNDI =
location, to be able to access the same database via the same pool. =
There is no way to enforce the equality, so you'll have to care yourself =
that the respective hibernate.cfg.xml and your JndiObjectFactoryBean =
definition match.

To support transactions spanning both Hibernate Sessions and plain JDBC =
access to the same DataSource, HibernateTransactionManager has a =
dataSource property that should be given the same DataSource reference =
(e.g. from a JndiObjectFactoryBean). It will export a transaction's JDBC =
connection for the specified DataSource then, just like =
DataSourceTransactionManager. Note that this doesn't involve JTA, thus =
no container-specific Hibernate JCA Connector setup - it even works in =
Tomcat. And in contrast to JTA, you can specify the isolation level per =
transaction.

Hibernate's transactional caching is a special issue: It's a hassle when =
using JTA without JCA because of the container-specific =
TransactionManager lookup, but it works nicely with =
HibernateTransactionManager. Thus, I wouldn't recommend =
JtaTransactionManager for accessing a single database via Hibernate =
and/or plain JDBC code from within Spring. HibernateTransactionManager, =
or DataSourceTransactionManager for plain JDBC only, gives the same =
level of convenience (+ custom isolation levels) without the =
container-specific hassle.

Note that we will try to provide similar support for JDO. We won't be =
able to export a JDO transaction's JDBC connection though (for =
transactions spanning plain JDBC access), or specify the isolation level =
per transaction. This is a consequence of JDO being datastore-agnostic, =
not assuming JDBC underneath. We would need to depend on a specific JDO =
implementation for such features.

Finally, if anyone has specific requirements or experiences in terms of =
datastore setup, feedback on our Hibernate support, or actual plans of =
using JDO - let me know! :-)=20

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG