[ 
https://issues.apache.org/jira/browse/AMQNET-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jim Gomes updated AMQNET-398:
-----------------------------
    Description: 
I needed to support ".NET style" distributed transactions with ActiveMQ broker 
and provided NMS WCF binding, but we can't get it working out of the box.
Because of WCF binding lacks explicit support for this scenario, I tried to 
fool it by supplying a wrapper for INetTxConnectionFactory (and a related one 
for INetTxConnection) as an IConnectionFactory through nmsprovider-*.config 
file.
Despite being able to make WCF binding to instantiate my wrapper class (and so, 
NetTxConnectionFactory under the hood), I needed to modify slightly WCF binding 
code in two points:

* NmsOutputChannel: here I noticed that a premature session disposing due to 
the using block caused a deadlock when the ISession implementation was 
NetTxSession who waits for transaction to complete 
(TransactionContext.DtcWaitHandle.WaitOne() in Close() method). This phenomenon 
was not evident in the provided test code, because of the TransactionScope 
block is always INSIDE the using block that scopes the session. Using WCF 
binding is somewhat higher level, so I'm forced to wrap the WCF call with a 
TransactionScope.
The modification I've made is to handle the non-transactional case like before, 
and to defer session disposing when inside a transaction (for this I've used 
provided events "TransactionCommittedListener" and 
"TransactionRolledBackListener").

* NmsInputChannelListener: assuming a service method with 
OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = 
true), my perception of the expected behavior when an exception is thrown in 
the service method is that the active transaction must be rolled back. Here we 
are on the receiving part (NMS WCF binding is below service code in the stack!) 
so to ensure this behavior (I stress this here: it's the expected behavior for 
me), I've had to provide a WCF custom IErrorHandler to raise an exception in 
HandleError method, that NMS WCF binding could be catch and rollback the active 
transaction.
To obtain this, I've had to rethrow the exception in Dispatch method. I don't 
know if this may cause troubles.

Morover, I discovered a bug in ActiveMQ provider NetTxConnection.GuidFromId: 
the implementation does not cares that the hyphen is a valid character 
hostnames.

I attach two patches here: one for the WCF binding component with the described 
changes, another for ActiveMQ provider with the transaction id translation fix 
and a minor one at a logging statement.

Best Regards,
Andrea Montemaggio

  was:
I needed to support ".NET style" distributed transactions with ActiveMQ broker 
and provided NMS WCF binding, but we can't get it working out of the box.
Because of WCF binding lacks explicit support for this scenario, I tried to 
fool it by supplying a wrapper for INetTxConnectionFactory (and a related one 
for INetTxConnection) as an IConnectionFactory through nmsprovider-*.config 
file.
Despite being able to make WCF binding to instantiate my wrapper class (and so, 
NetTxConnectionFactory under the hood), I needed to modify slightly WCF binding 
code in two points:
- NmsOutputChannel: here I noticed that a premature session disposing due to 
the using block caused a deadlock when the ISession implementation was 
NetTxSession who waits for transaction to complete 
(TransactionContext.DtcWaitHandle.WaitOne() in Close() method). This phenomenon 
was not evident in the provided test code, because of the TransactionScope 
block is always INSIDE the using block that scopes the session. Using WCF 
binding is somewhat higher level, so I'm forced to wrap the WCF call with a 
TransactionScope.
The modification I've made is to handle the non-transactional case like before, 
and to defer session disposing when inside a transaction (for this I've used 
provided events "TransactionCommittedListener" and 
"TransactionRolledBackListener").
- NmsInputChannelListener: assuming a service method with 
OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = 
true), my perception of the expected behavior when an exception is thrown in 
the service method is that the active transaction must be rolled back. Here we 
are on the receiving part (NMS WCF binding is below service code in the stack!) 
so
to ensure this behavior (I stress this here: it's the expected behavior for 
me), I've had to provide a WCF custom IErrorHandler to raise an exception in 
HandleError method, that NMS WCF binding could be catch and rollback the active 
transaction.
To obtain this, I've had to rethrow the exception in Dispatch method. I don't 
know if this cay cause troubles.

Morover, I discovered a bug in ActiveMQ provider NetTxConnection.GuidFromId: 
the implementation does not cares that the hyphen is a valid character 
hostnames.

I attach two patches here: one for the WCF binding component with the described 
changes, another for ActiveMQ provider with the transaction id translation fix 
and a minor one at a logging statement.

Best Regards,
Andrea Montemaggio


> NetTx transaction support in WCF binding
> ----------------------------------------
>
>                 Key: AMQNET-398
>                 URL: https://issues.apache.org/jira/browse/AMQNET-398
>             Project: ActiveMQ .Net
>          Issue Type: Improvement
>          Components: ActiveMQ, WCF
>            Reporter: Andrea Montemaggio
>            Assignee: Jim Gomes
>            Priority: Minor
>              Labels: transaction
>             Fix For: 1.7.1
>
>         Attachments: Apache.NMS.ActiveMQ-NetTx.patch, 
> Apache.NMS.WCF-NetTx.patch
>
>
> I needed to support ".NET style" distributed transactions with ActiveMQ 
> broker and provided NMS WCF binding, but we can't get it working out of the 
> box.
> Because of WCF binding lacks explicit support for this scenario, I tried to 
> fool it by supplying a wrapper for INetTxConnectionFactory (and a related one 
> for INetTxConnection) as an IConnectionFactory through nmsprovider-*.config 
> file.
> Despite being able to make WCF binding to instantiate my wrapper class (and 
> so, NetTxConnectionFactory under the hood), I needed to modify slightly WCF 
> binding code in two points:
> * NmsOutputChannel: here I noticed that a premature session disposing due to 
> the using block caused a deadlock when the ISession implementation was 
> NetTxSession who waits for transaction to complete 
> (TransactionContext.DtcWaitHandle.WaitOne() in Close() method). This 
> phenomenon was not evident in the provided test code, because of the 
> TransactionScope block is always INSIDE the using block that scopes the 
> session. Using WCF binding is somewhat higher level, so I'm forced to wrap 
> the WCF call with a TransactionScope.
> The modification I've made is to handle the non-transactional case like 
> before, and to defer session disposing when inside a transaction (for this 
> I've used provided events "TransactionCommittedListener" and 
> "TransactionRolledBackListener").
> * NmsInputChannelListener: assuming a service method with 
> OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = 
> true), my perception of the expected behavior when an exception is thrown in 
> the service method is that the active transaction must be rolled back. Here 
> we are on the receiving part (NMS WCF binding is below service code in the 
> stack!) so to ensure this behavior (I stress this here: it's the expected 
> behavior for me), I've had to provide a WCF custom IErrorHandler to raise an 
> exception in HandleError method, that NMS WCF binding could be catch and 
> rollback the active transaction.
> To obtain this, I've had to rethrow the exception in Dispatch method. I don't 
> know if this may cause troubles.
> Morover, I discovered a bug in ActiveMQ provider NetTxConnection.GuidFromId: 
> the implementation does not cares that the hyphen is a valid character 
> hostnames.
> I attach two patches here: one for the WCF binding component with the 
> described changes, another for ActiveMQ provider with the transaction id 
> translation fix and a minor one at a logging statement.
> Best Regards,
> Andrea Montemaggio



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to