Implement Object Pool design pattern for Hibernate Utility class?
We are using Hibernate for ORM in a non-managed environment.
In Presentation tier there is Struts which interacts with a POJO-based business model. In the Action class we instantiate a persistent object with data derived from the ActionForm. In the Action class we call the business method using a Business Delegate object that is stored and retrieved from the SessionContext.
Each user when they log into the application instantiates their own Business Delegate object.
The Business Delegate implements the business methods of the business model and uses a Hibernate utility class to do the data persistence. Hibernate is configured to use c3P0 for connection pooling.
Should we use the Object Pool design pattern to implement a pool for the Hibernate utility objects? Is this necessary?
Is the Hibernate Session Factory threadsafe?
Is there is JTA code in the Hibernate classes which implement transaction management processes automatically?
Is there is JTA code in the c3P0 classes which implement transaction management processes automatically?
# 1
> We are using Hibernate for ORM in a non-managed
> environment.
>
Love JPA. :^)
> In Presentation tier there is Struts which interacts
> with a POJO-based business model. In the Action class
> we instantiate a persistent object with data derived
> from the ActionForm. In the Action class we call the
> business method using a Business Delegate object that
> is stored and retrieved from the SessionContext.
>
> Each user when they log into the application
> instantiates their own Business Delegate object.
>
> The Business Delegate implements the business methods
> of the business model and uses a Hibernate utility
> class to do the data persistence. Hibernate is
> configured to use c3P0 for connection pooling.
>
Well, in this case, isn't the business delegate stateless (or at least could be written so)? See below for explanation.
> Should we use the Object Pool design pattern to
> implement a pool for the Hibernate utility objects?
> Is this necessary?
>
No. In fact probably counter-productive. SSLB's in EJB used object pooling as an 'optimization'. Better GC eventually did away with that justification for SLSB's (see Rod Johnson's "Programming J2EE without EJB's"). So, if the container cannot optimize it nowadays, I doubt a custom solution would either. Even Jakarta's.
> Is the Hibernate Session Factory threadsafe?
>
The factory should be thread-safe. The actual session is not.
> Is there is JTA code in the Hibernate classes which
> implement transaction management processes
> automatically?
>
Yes. Hibernate 3 and JPA implementations do so seamlessly.
> Is there is JTA code in the c3P0 classes which
> implement transaction management processes
> automatically?
Not to my knowledge. The pool is just to obtain a connection. This may or may not equate to an actual transaction. The pool does not worry itself about transaction, only about, pooling. :^)
- Saish
