Hello,

Daniel D'Alessandro and myself have written a short white paper on how we have sucessfully integrated Hibernate into a large scale, production J2EE application.

The paper outlines the goals behind the pattern, the methodology used and provides a downloadable implementation of the system.

A trivial application using the system wil be posted in the next few days utilising the code presented.

The whitepaper can be viewed at:

http://www.cassar.id.au/hibernate-j2ee

Source code implementing the pattern is available at the end of the paper.

We welcome any comments and discussion of our approach.

Just to summarise what we have done.

Basically we have expanded on the ThreadLocal pattern found on the hibernate.org site to integrate Hibernate transparently into a j2ee application server. We have expanded on this pattern to automatically assign new Hibernate sessions depending on the transaction demarcation and also to commit and close the sessions transparently when the container transaction commits.

Then there are a few added extras,
* Use of dynamic proxies to hide the hibernate specific code
* Externalised query Strings.

We believe this to be a significant enhancement to the threadlocal pattern and allows integration with minimal effort and impact to existing applications

Dan

Your post caught my eye - I am in the process of integrating (migrating as much as possible...) hibernate into an existing system composed of SLSBs and an absurd amount of BMP entities and direct-jdbc code. (entities only used for persistence framework, no special clustering or transactional use in play).

My initial approach is using Spring framework, using their simple callback/template processing. Its been mostly simple to design a data factory pattern that can rely on this framework for making the few simple hibernate calls into even fewer and simpler spring framework calls - my app is mostly providing the basis for extending this data factory to accomodate additional objects without treading on existing ones.

I haven't throughly checked out your code, but I will first thing tomorrow. I like the idea a lot, and it seems very simple and elegant.

I just wanted to see if you had considered Spring for this type of task? and if so, what are your opinions on why or why-not to use it for this?

Thanks
Tyson

Tyson

We hadn't really considered using Spring. By the time we had done most of our code etc we hadn't even heard of it. It was only through the post to the hibernate site that offered the Spring extension to the threadlocal pattern that we learned about it. It was gaining momentum then but we'd nearly finished so unfortunately I can't give you an informed opinion as to the benefits of one over the other. Tomorrow I'll download the spring distribution and have a look at their sample app!

Dan

Hi Tyson,

We have been using this framework since about March/April this year, several months before Spring came about, and have only now gotten around to releasing it to the Hibernate community so unfortunately I cannot comment on Spring as an alternative system.

I believe that you will find that the system will easily integrate with your existing entities and replace them transparently. The only catch will be the creation of the hibernate mappings (the round trip tools can help there) and the use of some kind of home factory to obtain your entity refs (it's prior use of making your migration far easier).

Hopefully in the next few days we will have an example app ready to show off the system. With the new cluster aware caches available for Hibernate I see no reason to use CMP/BMP ever again.

If you have any questions/comments let us know!

Hi -

I am looking more closely into this design, and I'm running into an issue:
- to create NEW persistent classes, I would like to create simple JavaBean implementations. Is this possible in this design?

It seems like there may be a couple of problems in attempting this:
1. does Proxy.newProxyInstance() work with concrete classes instead of interfaces? (I think it doesn't - is that correct?). If this is the case, perhaps this can be extended to use CGLIB for non-interface proxy creation (I believe this is how hibernate uses CGLIB?)

2. I think my JavaBean would need to implement an interface like EJBHome with methods like findByPrimaryKey(), etc. In my ideal situation for creating *new* persistent classes, I would not need to implement any special interfaces. I suppose I could put these methods within a base class with empty implementations of these methods?.

Basically, i would like to create a new persistent class by creating only a *single* new class, as opposed to EJB-like process of creating at least 2 classes (home and biz interfaces, and ejb implementation).

Any feedback on these ideas would be appreciated.

Thanks
Tyson

Correct, it doesn't.


It shouldn't be hard.


You could look into using the BeanGenerator class in CGLIB2. It lets you specify a base class (must have no-arg constructor) and the property names and types to put into the generated bean. Obviously you'd have to create the Hibernate mapping dynamically (at runtime), since you cannot predict the classnames of the generated classes.

Chris

This design requires both a 'home' interface specifying the finders, create/remove methods and javabeans representing the objects to be persisted. The framework continues using the same EJB patterns but with a different persistence mechanism.



No, an interface is required.

Honestly we never thought of this. So what you want is a 'single' bean representing both the persistent class AND the finders etc? I guess CGLIB could be used for this.



This approach requires a minimum of once class for persistence and one interface specifying the finders etc. Personally I like to keep my beans separate from these methods.

Tyson,

I've had a bit of a look at the spring sample application so I'll have a go at some comparisons.

Both approaches offer similar benefits. Spring utilises the Threadlocal and JTA to return an appropriate session and also to close that session transparently. Our approach mimics EJB to minimise the amount of change we had to perform whereas spring leans toward a DAO approach.

Spring can be configured to achieve exactly what we did but with a bit more overhead. I believe our approach is more transparent :) but I have to say that.

Spring provides a lot of functionality such as transaction demarcation for your hibernate calls. We just use the JTA from the container and register as a synchronization. We just want to tie hibernate in transparently, Spring replicates or replaces services that the appserver already provides.

In the end the results are very similar.

Dan

Dan,

A difference between your approach and Spring is indeed that you mimic Entity Beans while Spring builds on DAOs that conform to its generic DataAccessException hierarchy. Both aim to turn Hibernate data access code into an implementation detail in that respect.

Spring offers generic means for transaction demarcation, completely decoupled from Hibernate data access code or DAOs in the first place. The actual transaction strategy is pluggable: Out-of-the-box, HibernateTransactionManager (with a locally defined DataSource) and JtaTransactionManager (with container-managed transactional JNDI DataSources) are suitable for Hibernate.

I consider Spring's approach very transparent, but of course I have to say that ;-) The additional overhead that you see are Spring's transaction demarcation facilities, be it programmatic or declarative: They are not meant to be used in addition to EJB CMT but are intended as alternative to them. You can still leverage the container's JTA via JtaTransactionManager, you're just not using EJB then.

The Spring philosophy is not to replicate J2EE container services for the sake of doing it, but rather to use container services when appropriate and avoid being tied to them. For simple scenarios like a single database, you don't need distributed transactions via JTA, and a locally defined Commons DBCP BasicDataSource will be just fine: Spring offers respectively integrates simple alternative services here.

In comparison to writing local SLSBs just for leveraging CMT, setting up a Spring environment with AOP TransactionProxyFactoryBeans is much simpler. No EJB deployment descriptors, no classloader hassle, no unnecessary instance pooling that complicates resource singletons like a SessionFactory. And declarative transactions that just access a single database will even run on plain Tomcat!

Essentially, Spring allows to switch transaction strategies and DataSources as you need them: If you encounter a second database, you can easily switch to JtaTransactionManager and container DataSources. Your application code will not have to be touched - this is just a configuration change. And in unit tests, use mocks or simple non-J2EE strategies to be able to run your tests in a plain Java VM.

Hope that clarifies a couple of things,

Juergen

Juergen -

My current design has singleton "data factories" which extend HibernateDaoSupport and are initialized with the same SessionFactory.

Should I create a new HibernateTemplate for each query running in the same thread?

Currently, each query is creating a new Hibernate Session - I would like to reuse the session, so that my objects will take advantage of auto-dirty-checks.

Thanks for your feedback.

Tyson

Hi Juergen -

I think I have it working properly now, by calling:

before calls to HibernateDaoSupport.getHibernateTemplate().

I will change this to be:


so that it will only get inited when not active.

Does this sound reasonable? I could not determine a more appropriate way to reuse a ThreadLocal hibernate session from the "Data Access with Spring Framework" document - this might be a useful addition to that document? or did I missunderstand/misread somewhere?

Thanks for your help!

Tyson

Tyson

The spring stuff on the hibernate site can be supplemented by looking at the petclinic example in the spring distribution. This might help with useage patterns.

Dan