A few alternatives come to mind: 1) Does the cache really need a transaction manager? Is code external to the cache trying to start/commit transactions using DummyTransactionManager? If not, just remove the TransactionManagerLookupClass element. 2) Configure a real transaction manager in Tomcat and choose a TransactionManagerLookup that will find it. The first bit isn't trivial to do; I did it a couple years back after some research and experimentation, but don't remember the steps involved. But, if the purpose of the TransactionManager is anything at all beyond grouping together operations on the cache into a unit of work that can be committed/rolled back, you need to use a real TransactionManager. 3) You don't need a real TransactionManager and this TransactionManager you are using is only used by this cache and code that has access to this cache. In this case, you may not need the TransactionManager bound in JNDI. Instead, write a class like this: | package com.foo; | | public class FooTransactionManagerLookup implements TransactionManagerLookup | { | public TransactionManager getTransactionManager() throws Exception | { | // Don't call BatchModeTransactionManager.getInstance(), which tries | // to bind a singleton in JNDI -- just create one for our use | return new BatchModeTransactionManager(); | } | } | | Configure TransactionManagerLookupClass to use com.foo.FooTransactionManagerLookup. Code that needs to start transactions gets the TransactionManager from the cache by calling TreeCache.getTransactionManager(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4019984#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...