Allen, We selected JPA and JTA because they appear to be the standards for persistence and transaction currently. When you say incompatible, do you mean that the WebSphere transaction manager isn't JTA compliant, that we are using JTA features that WebSphere does not support, or that it is a custom transaction solution? Note that persistence and transactions is defined as an orthogonal concern, meaning you can easily replace it by another implementation without having to redefine everything. I'm more than happy to work with you on making this work on WebSphere. If you want to take a look at our transaction implementation, take a look at SingleSessionCommandService: http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-persiste... As you can see, there are only a few calls to the transaction manager before and after the execution of the commands (supporting both user-defined or default transactions). Shouldn't be too difficult to either replace that with another transaction implementation, or make the solution more generic to support multiple ones altogether. Kris Quoting Allen Day <DayAK(a)ldschurch.org&gt;: Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Kris, Thanks for your reply to my post. WebSphere Application Server does not expose the javax.transaction.TransactionManager interface to applications or application frameworks deployed into WebSphere Application Server. http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_... Specifically we've come to find that we cannot use the TransactionManager to: * Suspend Transactions * Register Transaction Synchronizations Looking at the source code you referenced it appears the TransactionManager interface is only being used to register a synchronization. Is there any other code you're aware of that uses the EnvironmentName.TRANSACTION_MANAGER? If not this is good because Websphere 7 supports JTA 1.1 which supports the TransactionSynchronizationRegistry. Is it possible for us to provide an alternative implementation of the SingleSessionCommandService? We would provide an implementation that uses the TransactionSynchronizationRegistry instead of TransactionManager. If you could point us in the right direction there that would be great. Otherwise perhaps we could just provide a dummy TransactionManager implementation that delegates to the TransactionSynchronizationRegistry? What do you think? Allen From: Mark Proctor [mailto:mproctor@codehaus.org] Sent: Wednesday, October 28, 2009 11:12 PM To: Rules Users List Cc: Allen Day Subject: Re: [rules-users] JTA question Kris Verlaenen wrote: Allen, We selected JPA and JTA because they appear to be the standards for persistence and transaction currently. When you say incompatible, do you mean that the WebSphere transaction manager isn't JTA compliant, that we are using JTA features that WebSphere does not support, or that it is a custom transaction solution? Note that persistence and transactions is defined as an orthogonal concern, meaning you can easily replace it by another implementation without having to redefine everything. I'm more than happy to work with you on making this work on WebSphere. If you want to take a look at our transaction implementation, take a look at SingleSessionCommandService: http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-persiste... As you can see, there are only a few calls to the transaction manager before and after the execution of the commands (supporting both user-defined or default transactions). Shouldn't be too difficult to either replace that with another transaction implementation, or make the solution more generic to support multiple ones altogether. I can concur that the plan was always to support other transaction models, but to target JTA first as it's an established standard. Beyond that we wanted to make sure our direction was user driven. Mark Kris Quoting Allen Day <DayAK@ldschurch.org><mailto:DayAK@ldschurch.org>: I am new to this list, so I apologize if this question has been asked before. It appears that drools-flow requires JTA in order to use JPA. Is anybody using drools-flow running on WebSphere, because WebSphere uses its' own transaction manager (and the two don't seem compatible). Has anybody looked at the feature request to provide support for resource local transactions - https://jira.jboss.org/jira/browse/JBRULES-2289 We need to decide soon between Drools Flow & JBPM, and this issue could swing in JBPM's favor. Thanks, Allen Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-users NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

Quoting Allen Day <DayAK(a)ldschurch.org&gt;: No, this class handles the transaction management. Sure, we use a provider strategy for getting the actual implementation. So you can use JPAKnowledgeService.setJPAKnowledgeServiceProvider to configure another provider. If you look at JPAKnowledgeServiceProviderImpl, it simply uses a property to specify the command service, so your own provider impl. should change that to use your custom implementation: props.setProperty( "drools.commandService", "org.drools.persistence.session.SingleSessionCommandService" ); Let us know how it goes, or if there is anything we could improve in our implementation to make this easier for you. Kris Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm