[rules-users] JTA question

[Mark Proctor]

Allen Day wrote:
>
> 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_alcott.html
>
>  
>
> 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? 
>
No it's only used for that synchronisation to drive the generation of 
the byte[] for change comparison.
>
> 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. 
>
This sounds reasonable, maybe we can make the sync callback pluggable.
>
> 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?
>
Yes i'd look at trying to build an interface that can be set as a 
strategy for callback handling.

Mark
>
>  
>
> Allen
>
>  
>
>  
>
> *From:* Mark Proctor [mailto:mproctor at 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-persistence-jpa/src/main/java/org/drools/persistence/session/SingleSessionCommandService.java
>  
> 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 at ldschurch.org> <mailto:DayAK at 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 at lists.jboss.org <mailto:rules-users at 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.
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20091029/625c3614/attachment.html