Hi,

I'm using Hibernate v3.0.5, and I'm receiving the following error:

org.hibernate.HibernateException: Unable to locate current JTA transaction

I get this error when I call:



My hibernate config file has the following parameters set:



I haven't received this error before. The recent change I have made is by adding a a second-level cache, treecache, but I'm not sure how adding the cache will cause this exception to occur. Are they related? Is it a bug? No clue.

Please help, thanks.

Nevermind, I'm dumb (but relieved!). I figured it out.

Obviously, I am a little bit thicker ;)... I got the same error. What is the problem? Thanks.

Are you using Hibernate in a managed environment; i.e., with an EJB ?

Well, even though I am running on JBoss 3.2.5 (yeah, old), but I am accessing Hibernate from both MBeans and EJB. EJB works fine (well, sort of, reason later), but MBeans obviously don't run in the context of a JTA (is there a way to make them? I am new to MBeans).

So, currently, I am resorting to the Session-in-ThreadLocal pattern to handle my sessions, rather than using getCurrentSession(). We don't have any inter-bean transaction, so I think this should be fine.

One question, though, I am running into the problem of my EJB not rollingback as expected. For example:

ejb1Method {
save();
query();
update();
}

I declare the above method as using CMT and "RequiresNew". But, if query() fails (and throws an uncaught RuntimeException to the container), save() still succeeds and the data makes its way into the database. I expect the save() to be rolled back and nothing gets saved into the database unless the entire ejb1Method() suceeds?!? BTW, I am using the "FlushBeforeCompletionEnabled" and "AutoCloseSessionEnabled" set to true.

Anyone ran into this CMT not rolling back correctly problem? Hibernate used is 3.0.4.

Thanks in advance,
Liem

So, from my understanding, the 'FlushBeforeCompletionEnabled' and 'AutoCloseSessionEnabled' attributes are specifically for the getCurrentSession() method, I don't think it works with the threadlocal pattern.

And in the EJB annotations, I specified the transaction type as "Required". It should work ..

Are you specifying the transaction manager and transaction manager lookup class in your hibernate.cfg.xml ?

Of course not, both are just not needed if you use getCurrentSession() and not your own ThreadLocal. However, ThreadLocal's are of dubious value in a multi-threaded application server. This is all explained in the reference documentation, which nobody wants to read anymore these days.

little error in ref 4.8.3 : managend environment

OK... So, now I have 2 ways to get to my Session, so that it works both for CMT and BMT/non-managed environments. For CMT, I use getCurrentSession(); for BMT/non-managed, I use my own Session management scheme (aka, the ThreadLocal session). Everything, including rollback, works like a charm! Thanks everyone for your help! You guys are awesome.

But, now here is another quandary: How can I tell if I get called from a CMT versus non-managed environment, to know if I should call openSession() or getCurrentSession()? I am trying to abstract the concept of Session from client code.

Thanks,
Liem

i'm using hibernate in a managed environment with weblogic. getCurrentSession() works when i use transaction typ "Required", "Required New". but i get the above mentioned exception as soon as i use transaction typ "Supports", "Not Supported".

the javadoc of getCurrentSession() states that a transaction must already be in effect prior to calling this method. imo this means i can't use "Supports" with getCurrentSession(). what are the alternatives in a managed environment ?

greetings from berne
jakob

I would like to see how you got your session in both the managed and non-managed ways?

The workaround I did is basically check to see if I am in a JTA transaction before invoking getCurrentSession(). If I am not in a JTA transaction, then I use openSession() instead (via the ThreadLocal pattern). I wrap all this in a convenient method, so clients get a session the same way, disregard of where they come from.

we're using a similar solution but first we try getCurrentSession() and in case of an exception openSession() and a ThreadLocal is used.

do you explicitely close the session ?

jakob

Yes, I explicitly close the session. It is usually better to check for the exception condition than to catch it, because you will incur exception stack trace cost. My 2 cents.

thanks for your answer. how do you check the current jta-transaction ?

i was thinking of changing the implemenation of SessionFactoryImpl, because imo hibernate should create a session if it cannot obtain the current one. my implementation creates and returns a SessionImpl with the same settings as in getCurrentSession(). so i think (hope...) that callers of SessionFactoryImpl#getCurrentSession should not need to care where the session is coming from.

jakob