You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by "Anjana Fernando (JIRA)" <ji...@apache.org> on 2011/05/23 11:05:47 UTC
[jira] [Created] (WSCOMMONS-566) JMS Transactions Not Replayed with
transport.Transactionality=jta and transport.jms.SessionTransacted=true
JMS Transactions Not Replayed with transport.Transactionality=jta and transport.jms.SessionTransacted=true
----------------------------------------------------------------------------------------------------------
Key: WSCOMMONS-566
URL: https://issues.apache.org/jira/browse/WSCOMMONS-566
Project: WS-Commons
Issue Type: Bug
Components: Transport
Affects Versions: Transports 1.1
Reporter: Anjana Fernando
In the JMS transport, when using JTA transactions, and if you set transport.jms.SessionTransacted=true, then the the transaction mode changes to "local" automatically. Some transaction providers, i.e. Atomikos, requires you set SessionTransacted to true or else, it will not work properly [1]. Basically, it will not replay the transactions if the distributed transaction fails.
So basically, it should be possible to set both transport.Transactionality=jta and transport.jms.SessionTransacted=true independantly without interfering with each other. The current logic in the code is, if transport.Transactionality=local, it sets transport.jms.SessionTransacted=true automatically, which is OK, but also when you set transport.jms.SessionTransacted=true, it sets transport.Transactionality=local, which should not happen, where the user should have the option to override that behaviour.
[1] http://fogbugz.atomikos.com/default.asp?community.6.1268.1
Cheers,
Anjana.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] [Updated] (WSCOMMONS-566) JMS Transactions Not Replayed with
transport.Transactionality=jta and transport.jms.SessionTransacted=true
Posted by "Anjana Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Anjana Fernando updated WSCOMMONS-566:
--------------------------------------
Attachment: WSCOMMONS-566-Patch.txt
Hi,
Attaching a patch to solve the mentioned issue, this simply changes the setter method for "setSessionTransacted" to not to change the "transactionality" property.
Cheers,
Anjana.
> JMS Transactions Not Replayed with transport.Transactionality=jta and transport.jms.SessionTransacted=true
> ----------------------------------------------------------------------------------------------------------
>
> Key: WSCOMMONS-566
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-566
> Project: WS-Commons
> Issue Type: Bug
> Components: Transport
> Affects Versions: Transports 1.1
> Reporter: Anjana Fernando
> Attachments: WSCOMMONS-566-Patch.txt
>
>
> In the JMS transport, when using JTA transactions, and if you set transport.jms.SessionTransacted=true, then the the transaction mode changes to "local" automatically. Some transaction providers, i.e. Atomikos, requires you set SessionTransacted to true or else, it will not work properly [1]. Basically, it will not replay the transactions if the distributed transaction fails.
> So basically, it should be possible to set both transport.Transactionality=jta and transport.jms.SessionTransacted=true independantly without interfering with each other. The current logic in the code is, if transport.Transactionality=local, it sets transport.jms.SessionTransacted=true automatically, which is OK, but also when you set transport.jms.SessionTransacted=true, it sets transport.Transactionality=local, which should not happen, where the user should have the option to override that behaviour.
> [1] http://fogbugz.atomikos.com/default.asp?community.6.1268.1
> Cheers,
> Anjana.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org