We have an application that we are looking at converting to using Hibernate.

We are already running inside of JBoss 4, with CMT for our session facades that are access from our servlet.

Ideally, I would like to leverage the Hibernate/JBossAS integration to be able to 1) handle CMT Tx and 2) use getCurrentSession().

However, one thing in the JBoss Wiki about this caught my eye, and I was wondering if I could get some clairification. It mentions that you *have* to have a running JTA Tx to be able to get the current Hibernate Session. Is this really true?

Ideally, I would like to have one Hibernate Session that's lifecycle is directly tied to my servlet request lifecycle, and at the same time, allow 1 or more JTA Tx's to participate in it.

For instance, here is a typical example of one of our requests:

-Servlet Request comes in
- Call is made to SLSB to log request (this requires a complete TX that is committed)
- Various calls are made from the servlet level to a the persistence level (in this case Hibernate) to retrieve data, this could, or could not happen inside the scope of a JTA TX.
- Domain object is updated, and passed to another SLSB for validation and persistence (with the EJB method call being marked for 'Requires', so a new TX is created).

So, in this case, 2 different JTA-TX's are created and commited, and there is Hibernate work that will also happen outside of JTA-TX.

And, as I said, ideally, this would happen within the lifecycle of one Hibernate Session (mainly to ensure that the entire request can share the same local cache for instance creation).

Thoughts? Am I asking to much? I think I can accomplish this on my own if I manage my own SessionFactory and Sessions, I think.

Thanks!

So how do you propose a call to org.hibernate.SessionFactory.getCurrentSession() know about the "current http servlet request"?

I completely get what you are saying. JBoss needs the JTA demarcation as a hook in to start the process. The more I think about it, the more I understand the that problem. I guess what I want clarification on is if that problem is mearly that -- a hook is needed -- or is it also because of the fundemental design of the Session?

So, given that I can't use getCurrentSession(), is there anything that keeps from doing the following:

1) Continue to use the HAR deployment, but do my own Session management?

Having a package structure that will auto-add the config files without having to specifiy each one would be nice. I am assuming that the SessionFactory is bound to JNDI at deployment-time, so if I manage the retrieval of it, creating sessions and binding them myself to the requests, are there any issues?

2) Use a single 'long-lived' Session for each HTTP request that will participate in at least 1, but usually mroe than one CMT JTA-TX, including doing retrievals that are not in the context of a JTA-TX?

Everything I have read leads me to believe that there is no issue with this, but the JTA requirement to use getCurentSession(), I just wanted to confirm.

Thanks!