The solution : This is how I got my TransactionManager from JBoss server TransactionManager tm = (org.jboss.tm.TxManager) new InitialContext().lookup("java:/TransactionManager"); and I used this to inject into runtime config. Jboss cache was doing one of the 2 things 1. In GenericTransactionManagerLookup the code is if (jndiObject instanceof TransactionManager) | { | tm = (TransactionManager) jndiObject; | log.debug("Found TransactionManager for " + knownJNDIManager[1]); | return; | } | The "instanceof" condition was failing as class org.jboss.tm.TXManager implements TransactionManager 2. Within JBossTransactionManagerLookup this statement was throwing a class cast Exception return (TransactionManager) new InitialContext().lookup("java:/TransactionManager"); Again for the same reason. When I do upgrade to Jboss 4.2.3 Jboss was returning me a different and the same problems existed. When I downgrade the jboss-cache version, The exact same code was present , which meant I was getting the exact same problems. I am not sure on how to approach this problem as the code I have done is dirty as it uses "Jboss server" specific jars in classpath to compile. Please do suggest on how to handle this. I have another question though. Spring manages my transactions for all my service classes. And all my jboss cache calls are happening from within a service class. If spring calls its "rollback / commit" at End of teh service method, would it be rolled back / committed to the jboss cache too? Thanks for your help so far. I totally appreciate you taking the time to answer me. -Sundar View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207094#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...