Hello all,

So far as I can tell, it appears you need to write two different implementations of a DAO if you intend on using Hibernate. The root of the problem seems to rely on the fact that Hibernate requires "Database transaction demarcation" to work its magic.

Link: http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html#transactions-demarcation


The Hibernate docs state that when implementing a DAO in an unmanaged (i.e. standalone) environment you should utilize hibernates internal transaction management system (org.hibernate.transaction.JDBCTransactionFactory).

However what I am unclear about is can I and more to the point, SHOULD I use this transaction demarcation method in a managed environment as well. If so what are the pros and cons between this style and using JTA as the transaction manager/demarcation mechanism.

Thanks in Advance,

Richard Wareing
[/url]

In a managed env, just use CMT together with SessionFactory.getCurrentSession()

Thanks for the quick reply. Does this mean I would have to do two DAO implementations one for stanalone and one for CMT? I was trying to avoid this :).

Rich...

Certainly NOT. DAOs do not do transaction/session management!

What are the chances of getting something like this that doesn't use getCurrentSession() ?

http://cvs.sourceforge.net/viewcvs.py/h ... &view=auto

But isn't that the reason you need to implement two DAO implementations? i.e. in a managed (JTA) environment your dao code would look something like this:

public interface StuffDAO {
public Stuff getStuff( String name );
}

public class CMTStuffDAOImpl implements StuffDAO {

public Stuff getStuff( String name ) {
Session sess = factory.getCurrentSession();
// code to get stuff....
} // method

} // class


Where as in unmanaged environment it would look like this:

public class StandAloneStuffDAOImpl implements StuffDAO {

public Stuff getStuff( String name ) {
Session sess = factory.openSession();
Transaction tx = null;
try {
tx = sess.beginTransaction();
// code to get stuff....
tx.commit();
} catch (RuntimeException e) {
if (tx != null) tx.rollback();
throw e; // or display error message
} finally {
sess.close();
} // try
} // method
} // class

Rich...

Really the DAOs should not even be opening the hibernate sessions themselves. Typically this should be a higher-level function; the DAOs then just look up the session from a "well known place". Think about two DAOs needing to interact within the same logical unit-of-work...

A nice strategy for this is to use proxies for wrapping the things coordinating access to the DAOs. The proxy would handle things like session and transaction management.

public class StandAloneStuffDAOImpl implements StuffDAO {

public Stuff getStuff( String name ) {
Session sess = currentSession();//a typical use case for thread local
// code to get stuff....

} // method
} // class

Ok so let me summarize what I've understood so far:

1. CMT Environments - Get the session via the factory.getCurrentSession() method (i.e. let JTA manage things and demarcate the transaction boundaries).

2. Standalone Environments - Use a HibernateUtil/ThreadLocal pattern to externally store the current session in a "well known" place, and have your DAOs retrieve the current session from there or alternately a proxy. This insulates you from the very likely scenario of the "unit of work" not being complete in any particular DAO method.

3. For an application that requires a standalone server in addition to a application server component, you need two DAO implementations: one for the standalone server (implemented ala #2) and one for the application server (implemented ala #1).

Do I have all this right? :) Also, could you point me to any place where I can RTFM on this proxy you speak of?


Thanks in Advance,

Richard...

P.S. As usual you guys have been of great help, thanks for all your comments!

With Spring you can have one implementation and two xml's. In our application we using this approach - the same code is working in 3-tier and 2-tier versions.

Well I'm trying to get away with not using Spring at all in the standalone portion of the project. So I'm not sure that would work :).

It sounds like to really accomplish what I'd like (only one DAO implementation) I'd need to use a JTA based transaction manager and wire it up to Hibernate some how. That way when from inside the Hibernate DAO implementation the factory.getCurrentSession() method is called it should work.

However it sounds like doing this would be alot more grief than it's worth (plus I can't find documentation on this anywhere), so I'm now investigating the suggested "proxy" method, and if I can't figure that out I'll resort to the HibernateUtil strategy.

Richard...

hello all,

i am also currently trying to combine christians "Generic DAO pattern with
JDK 5.0" with a standalone application. since the usage of servlet-filters
isn't possible and because i would also like to avoid using spring, the proxy
method mentioned before seems to be the only other possibility.

can anyone give me a quick explanation of how this would be implemented?

that would be a great help!

thanks in advance,
nick

http://hibernate.org/43.html has links and hints.

thanks for the link christian,

but i already read those pages and still don't quite get it! i know you have
answered so many similar questions bevor and i don't want to annoy you
with this!

i am using hibernate 3.1rc3, so that i can set the "current_session_context_class"
configuration option to "thread" in order to use the ThreadLocal feature.

i do understand, that this creates a new session if none is available, but
how and where do i write the transaction demarcation code as well as the
code for closing the session, if this doesn't belong into the DAOs.

i need something between my application code and the DAOs to decouple the
application from the hibernate framework and the transaction code altogether.
one solution mentioned would be AOP, which i would like to avoid.

the "proxy" method sounds promising! has anybody done this and could give
me (a confused newbie) a quick explanation...

thanks,
nick