Thanks for the suggestion, Mare.
The transaction manager is where I'm having problem with.
According to this: http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html
"...to ensure the integrity of transaction context management (and hence the proper management of transactional resources) WebSphere Application Server does not expose the javax.transaction.TransactionManager interface to applications or application frameworks deployed into WebSphere Application Server."
As far as I know, both Hibernate and Spring have something of their own to work around this problem, something like :
- org.hibernate.transaction.WebSphereExtendedJTATransactionLookup
- org.springframework.transaction.jta.WebSphereUowTransactionManager
While I do not know the how Spring and Hibernate work around on TransactionManager, I found a work-around to this problem; and it goes in 2 parts :--
1. WebSphere does not like threads being created in EJB.
The first part of the solution is to fix the threads created directly using J2SE. The class doing that is : org.drools.time.impl.JDKTimerService. Using the example and classes from: http://www.ibm.com/developerworks/websphere/techjournal/0606_johnson/0606_johnson.html I was then able to create the thread pool using the WebSphere's WorkerManager. Now, the threads under this are under J2EE context.
2. Re-initialize the "UserTransaction"
When the timer service kicks in, it tries to call the single command service class (forgot actual class at the moment). I perform a JNDI UserTransaction lookup to make it so that the drools transaction manager is new.
I'll try to put a few pieces of code in here later.
Gary