I want to use Hibernate's TreeCacheProvider and I've seen several documents and postings that lead me to believe that TreeCache requires a JTA environment. But there are several others that lead me to believe that I don't.

I've got a simple environment with only one database, so JTA seems like overkill.

Is JTA required for JBoss TreeCache to work properly in a distributed caching environment?

JTA is needed in managed environmnet, so if you would like to leave controling of transaction to application server (container), you must use JTA, because container is using JTA.

In more detail, you can deploy session bean as container managed, and you don't need to write beginTransaction, commit, etc., the conainer will call it - calling JTA.

Hi, I have declared a session bean method with transaction NotSupported. When I get the Hibernate session using HibernateContext.getSession("") it throws a NullPointer. Do you have any advice on performing read-only operations, i.e. not using a transaction?

Thanks,

Ted

Ted - check out this post by steve:

http://forum.hibernate.org/viewtopic.php?t=935865

You may get a clearer error message if you update to the latest code

Hi drj,

I downloaded jboss 3.2.7RC1 and I did get a better error message:



But does this mean I must use tx even for a read-only operation. Do I have to get an unmanaged HibernateSession in this instance? That seems like a bad pattern, get one session for write-operation but get session differently for read-operation?

Should I use a different transaction declaration for the session bean method?

Thanks,

Ted

There are two scenarios:

1. You get session via HibernateContext.getSession() and container will do all session management work for you. You must be in TX to take advantage of it because TX used to demarcate hibernate session lifetime. The great advantage that calling getSession() from different components sharing the same transaction you'll get the same hibernate session which will be closed by container just before TX commit.

2. You can get unmanaged session via HibernateContext.getUnmanagedSession(). Then you should dispose it yourself using HibernateContext.releaseUnmanagedSession() in finally block. It is far less convinient then first option but for contexts where TX is not necessary it's better option.

In my expirience, you should avoid creating transaction only because you want hibernate session management. It creates huge overhead and inappropriate, for example, for heavy loaded servlets which just access some read-only data via hibernate.

PS hmm just looked into sources.. Actual getUnmanagedSession() is not exactly what I expected (and what it is in my own implementation), seems it wants TX as well..
Anyway, you can implement what I mean unmanagedSession yourself - just lookup hibernate session factory in JNDI and create new session. like this:

SessionFactory sessionFactory = (SessionFactory) new InitialContext().lookup(SESSION_FACTORY_JNDI_NAME);

Session session = sessionFactory.openSession();

Hi Octopus,

Thank you for your reply. I would like to access the Hibernate Session in a consistent fashion for either Tx or NonTx operations. However if this is not possible using HibernateContext then I will use the SessionFactory directly from JNDI for operations without a Tx.

How do I enter a feature request such that HibernateContext will return a Session that is disconnected from a Tx? Are there any reasons that one would not want to do this?

Thanks,

Ted

Right, I'd like the same. There was a long discussion here with Steve after 1st iteration. Current version is trade-off which doesn't solve everything..

Let me briefly explain the problem.

The perfect solution would be to be able to call getSession() anywhere, get correct session and get it closed automatically when necessary.

To do this, container need to know hibernate session boundaries and be able to define context when getSession called.

In first version, session context was defined by either EJB interceptor or servlet filter which have to be applied to all components using hibernate. Even so it didn't always provide correct behavoiur.

For example: Servlet calls EJB which calls another EJB. All of them call getSession(). How container can find out that all these calls are from the same context and it needs to provide them the same session. Another problem is when to close session.

Since nobody yet clearly described correct behaviour in cases like this starting with version 2 hibernite session binds to current transaction. It is perfect for transactional context because hibernate session matches transaction lifecycle. But it doesn't solve the issue with non-TX contexts.

Any ideas of how it can be done would be appreciated.

This will not happen.

Even read operations should have transaction isolation.

Steve,

could you clarify the poing of having transaction isolation for read-only data? What will it bring to me besides HUGE overhead?

For example, I have huge amount of read-only data (historical stock quotes). Suppose I have a servlet which provides this data to clients.
Now I access hibernate session there in a traditional way, load my read-only entities and close hibernate session in finally block. When I tried to open transaction there I get 10x fall in productivity. Since I serve thousands of requests like this per second it is absolutely inappropriate. Do you think I really need transaction isolation here?

Sorry, but its the other way around. You have to tell US why you think that read operations don't require proper transaction demarcation (no, "I use Oracle or another MVCC database" doesn't count).

You also seem to have problems understanding transactions. What you want is auto-commit behavior. Configure your session beans accordingly, one transaction per method call, problem solved.

I would say the contrary actually since you DB will not have to build tons of small transaction contexts

emmanuel, cristian,

you're right, of course I know what autocommit is. In that example the reason was I'm using jboss cache and vast majority of requests don't go to DB at all. So I dismiss my post as irrelevant.