activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Guggi <daniel.gu...@gmail.com>
Subject Re: XA Transaction with multiple xa-connections not working on rollback
Date Sat, 06 Apr 2013 20:24:25 GMT
i changed TransactionContext.getResourceManagerId to also append the
connections clientid

private String getResourceManagerId() throws JMSException {
        return this.connection.getResourceManagerId() + "/" +
this.connection.getClientID();
    }

therefor isSameRM() now only returns true for xaresources based on the same
amq-connection.

now everything works as expected, but don't know if this would be a valid
approach (or even the right place) to fix this :)

ty




On Sat, Apr 6, 2013 at 9:53 PM, Daniel Guggi <daniel.guggi@gmail.com> wrote:

> the jta spec says:
>
> 3.4.6 Resource Sharing
> When the same transactional resource is used to interleave multiple
> transactions, it is
> the responsibility of the application server to ensure that only one
> transaction is enlisted
> with the resource at any given time.
>
>
>
>
>
>
>
> On Sat, Apr 6, 2013 at 9:41 PM, Daniel Guggi <daniel.guggi@gmail.com>wrote:
>
>> glassfish code just does that:
>>
>> it know the following resources states (one TransactionContext per
>> connection - same xid,same branch => imo ok because
>> TransactionContext.isSameRM returns true)
>>
>>
>> TransactionContext{transactionId=XID[4871251,globalId=4000ffffffcaffffff98ffffffceffffffe064676e622c7365727665722c50313030,branchId=64676e622c7365727665722c503130302c0]}=0,
>>
>> TransactionContext{transactionId=XID:[4871251,globalId=4000ffffffcaffffff98ffffffceffffffe064676e622c7365727665722c50313030,branchId=64676e622c7365727665722c503130302c0]}=0
>>
>> on rollback glassfish just calls end(xid,flags) once per xaresource (the
>> xa resources above are equal i guess)
>>
>> on commit glassfish calls end(xid,flags) for every resource state
>> (transactioncontext)
>>
>> don't know if this is correct - i didn't find anything in the jta-specs...
>>
>> or maybe it is wrong to consider that two xa resources are equal for
>> different activemq-connections -> TransactionContext.isSameRM()
>>
>> daniel
>>
>>
>>
>> On Sat, Apr 6, 2013 at 8:48 PM, Daniel Guggi <daniel.guggi@gmail.com>wrote:
>>
>>> i forget to mention.
>>>
>>> when we do not throw an exception after the jms-template send everything
>>> works fine - transaction gets committed org.apache.activemq.
>>> TransactionContext.end(xid,flags) is called twice as expected...
>>>
>>>
>>>
>>>
>>> On Sat, Apr 6, 2013 at 8:46 PM, Daniel Guggi <daniel.guggi@gmail.com>wrote:
>>>
>>>> hi,
>>>>
>>>> we use spring's DMLC using an xa-pooledconnectionfactory
>>>>
>>>> when the DMLC receives a message the (test) message-lister just sends a
>>>> message to another queue using spring's jmstemplate. this jms-template also
>>>> uses a xa-pooledconnectionfactory (but another instance)
>>>>
>>>> that meas that we have two activemq xa-connections - one by the
>>>> listener and the other by the jms-template
>>>>
>>>> if the message-listener throws a runtime-exception after jmstemplate
>>>> send, the rollback is not properly performed.
>>>>
>>>> i can see that org.apache.activemq.TransactionContext.end(xid,flags) is
>>>> only called once for the dmlc-connection - so therefore no rollback is not
>>>> performed for the other xa-connection/session, which leads to a (jta)
>>>> system-exception on the next-message, because the pooldcf returns the
>>>> cached session
>>>>
>>>> any ideas how this could happen - this might be a jta issue? btw. we
>>>> are using glassfish-3.1.2.2
>>>>
>>>> thank you,
>>>> daniel
>>>>
>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message