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#4019984
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4019984
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
