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:[email protected]]
*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 <[email protected]> <mailto:[email protected]>:
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
[email protected] <mailto:[email protected]>
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
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
