[JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reassigned JBTM-2848:
-----------------------------------
Assignee: David Lloyd (was: Tom Jenkinson)
> Transaction .equals() methods do not comply with specification
> --------------------------------------------------------------
>
> Key: JBTM-2848
> URL: https://issues.jboss.org/browse/JBTM-2848
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Reporter: David Lloyd
> Assignee: David Lloyd
> Priority: Blocker
> Fix For: 5.next
>
>
> The JTA specification has this to say about Transaction.equals():
> {quote}
> The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction.
> For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method.
> {code}
> Transaction txObj = TransactionManager.getTransaction();
> Transaction someOtherTxObj = ..
> ..
> boolean isSame = txObj.equals(someOtherTxObj);
> {code}
> In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal.
> {quote}
> There are several transaction implementation classes in Narayana including:
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}}
> Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail.
> I'll provide a PR that fixes the issue which you can use if you want.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2848:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Transaction .equals() methods do not comply with specification
> --------------------------------------------------------------
>
> Key: JBTM-2848
> URL: https://issues.jboss.org/browse/JBTM-2848
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Reporter: David Lloyd
> Assignee: David Lloyd
> Priority: Blocker
> Fix For: 5.next
>
>
> The JTA specification has this to say about Transaction.equals():
> {quote}
> The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction.
> For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method.
> {code}
> Transaction txObj = TransactionManager.getTransaction();
> Transaction someOtherTxObj = ..
> ..
> boolean isSame = txObj.equals(someOtherTxObj);
> {code}
> In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal.
> {quote}
> There are several transaction implementation classes in Narayana including:
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}}
> Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail.
> I'll provide a PR that fixes the issue which you can use if you want.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on JBTM-2848:
-----------------------------------
I would say it's not the only 10+ year old bug in our code base :)
> Transaction .equals() methods do not comply with specification
> --------------------------------------------------------------
>
> Key: JBTM-2848
> URL: https://issues.jboss.org/browse/JBTM-2848
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Reporter: David Lloyd
> Assignee: Tom Jenkinson
> Priority: Blocker
>
> The JTA specification has this to say about Transaction.equals():
> {quote}
> The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction.
> For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method.
> {code}
> Transaction txObj = TransactionManager.getTransaction();
> Transaction someOtherTxObj = ..
> ..
> boolean isSame = txObj.equals(someOtherTxObj);
> {code}
> In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal.
> {quote}
> There are several transaction implementation classes in Narayana including:
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}}
> Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail.
> I'll provide a PR that fixes the issue which you can use if you want.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned JBTM-2848:
---------------------------------
Assignee: David Lloyd (was: Ondra Chaloupka)
> Transaction .equals() methods do not comply with specification
> --------------------------------------------------------------
>
> Key: JBTM-2848
> URL: https://issues.jboss.org/browse/JBTM-2848
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Reporter: David Lloyd
> Assignee: David Lloyd
> Priority: Blocker
>
> The JTA specification has this to say about Transaction.equals():
> {quote}
> The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction.
> For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method.
> {code}
> Transaction txObj = TransactionManager.getTransaction();
> Transaction someOtherTxObj = ..
> ..
> boolean isSame = txObj.equals(someOtherTxObj);
> {code}
> In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal.
> {quote}
> There are several transaction implementation classes in Narayana including:
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}}
> Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail.
> I'll provide a PR that fixes the issue which you can use if you want.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned JBTM-2848:
---------------------------------
Assignee: Tom Jenkinson (was: David Lloyd)
> Transaction .equals() methods do not comply with specification
> --------------------------------------------------------------
>
> Key: JBTM-2848
> URL: https://issues.jboss.org/browse/JBTM-2848
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Reporter: David Lloyd
> Assignee: Tom Jenkinson
> Priority: Blocker
>
> The JTA specification has this to say about Transaction.equals():
> {quote}
> The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction.
> For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method.
> {code}
> Transaction txObj = TransactionManager.getTransaction();
> Transaction someOtherTxObj = ..
> ..
> boolean isSame = txObj.equals(someOtherTxObj);
> {code}
> In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal.
> {quote}
> There are several transaction implementation classes in Narayana including:
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}}
> Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail.
> I'll provide a PR that fixes the issue which you can use if you want.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2848:
-------------------------------------
I would say though that this behaviour has existing in Narayana since it was imported into svn at Red Hat 11 years ago.
> Transaction .equals() methods do not comply with specification
> --------------------------------------------------------------
>
> Key: JBTM-2848
> URL: https://issues.jboss.org/browse/JBTM-2848
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Reporter: David Lloyd
> Assignee: Ondra Chaloupka
> Priority: Blocker
>
> The JTA specification has this to say about Transaction.equals():
> {quote}
> The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction.
> For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method.
> {code}
> Transaction txObj = TransactionManager.getTransaction();
> Transaction someOtherTxObj = ..
> ..
> boolean isSame = txObj.equals(someOtherTxObj);
> {code}
> In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal.
> {quote}
> There are several transaction implementation classes in Narayana including:
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}}
> Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail.
> I'll provide a PR that fixes the issue which you can use if you want.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2848:
-------------------------------------
Let's see how CI goes. I do take your point about equality based on both referring to the same global transaction.
> Transaction .equals() methods do not comply with specification
> --------------------------------------------------------------
>
> Key: JBTM-2848
> URL: https://issues.jboss.org/browse/JBTM-2848
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Reporter: David Lloyd
> Assignee: Ondra Chaloupka
> Priority: Blocker
>
> The JTA specification has this to say about Transaction.equals():
> {quote}
> The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction.
> For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method.
> {code}
> Transaction txObj = TransactionManager.getTransaction();
> Transaction someOtherTxObj = ..
> ..
> boolean isSame = txObj.equals(someOtherTxObj);
> {code}
> In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal.
> {quote}
> There are several transaction implementation classes in Narayana including:
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}}
> Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail.
> I'll provide a PR that fixes the issue which you can use if you want.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on JBTM-2848:
-----------------------------------
The JTA specification seems pretty clear on the point. Also in terms of best practices, whether or not you can do the same operations doesn't typically have any bearing on the equals/hashCode contract, generally speaking, so already it's a pretty unusual case, the more so because hashCode does not discriminate by type; it's hard to imagine any correctness issue that this behavior actually solves. If a user needs to discriminate based purely on behavior or available operations, they would naturally examine the type themselves using any number of common idioms as they would for any other type.
>From the container code perspective, I probably can adjust to assume that the implementation doesn't actually conform to specification in some places but as long as Narayana is returning different types in different situations for the same XID, at some point this is going to cause an issue because I've relied on this aspect of the specification for quite a long time. If the importer always returns the same type for a given XID then that's probably enough to conform to the specification (barring the case where someone manually manufactures an invalid TransactionImple) and also makes my problem go away; I just went for the solution that I see as more practical, correct, and idiomatic.
> Transaction .equals() methods do not comply with specification
> --------------------------------------------------------------
>
> Key: JBTM-2848
> URL: https://issues.jboss.org/browse/JBTM-2848
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Reporter: David Lloyd
> Assignee: Ondra Chaloupka
> Priority: Blocker
>
> The JTA specification has this to say about Transaction.equals():
> {quote}
> The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction.
> For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method.
> {code}
> Transaction txObj = TransactionManager.getTransaction();
> Transaction someOtherTxObj = ..
> ..
> boolean isSame = txObj.equals(someOtherTxObj);
> {code}
> In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal.
> {quote}
> There are several transaction implementation classes in Narayana including:
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}}
> Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail.
> I'll provide a PR that fixes the issue which you can use if you want.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2848:
-------------------------------------
Hi [~dmlloyd] - this is by intention. The subordinate types are not intended to be equal to the root coordinator types because you can't do the same types of operation on both. For example, a key difference between the two is the implementation of commit:
https://github.com/dmlloyd/narayana/blob/master/ArjunaJTA/jta/classes/com...
If all you need is some way to access the UID to test for same global transaction ID we can move https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com... or https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com... to the SPI?
> Transaction .equals() methods do not comply with specification
> --------------------------------------------------------------
>
> Key: JBTM-2848
> URL: https://issues.jboss.org/browse/JBTM-2848
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Reporter: David Lloyd
> Assignee: Ondra Chaloupka
> Priority: Blocker
>
> The JTA specification has this to say about Transaction.equals():
> {quote}
> The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction.
> For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method.
> {code}
> Transaction txObj = TransactionManager.getTransaction();
> Transaction someOtherTxObj = ..
> ..
> boolean isSame = txObj.equals(someOtherTxObj);
> {code}
> In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal.
> {quote}
> There are several transaction implementation classes in Narayana including:
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}}
> Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail.
> I'll provide a PR that fixes the issue which you can use if you want.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (JBTM-2848) Transaction .equals() methods do not comply with specification
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/JBTM-2848?page=com.atlassian.jira.plugin.... ]
Kabir Khan reassigned JBTM-2848:
--------------------------------
Assignee: Ondra Chaloupka
> Transaction .equals() methods do not comply with specification
> --------------------------------------------------------------
>
> Key: JBTM-2848
> URL: https://issues.jboss.org/browse/JBTM-2848
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Reporter: David Lloyd
> Assignee: Ondra Chaloupka
> Priority: Blocker
>
> The JTA specification has this to say about Transaction.equals():
> {quote}
> The transaction manager must implement the Transaction object's {{equals}} method to allow comparison between the target object and another Transaction object. The {{equals}} method should return {{true}} if the target object and the parameter object both refer to the same global transaction.
> For example, the application server may need to compare two Transaction objects when trying to reuse a resource that is already enlisted with a transaction. This can be done using the {{equals}} method.
> {code}
> Transaction txObj = TransactionManager.getTransaction();
> Transaction someOtherTxObj = ..
> ..
> boolean isSame = txObj.equals(someOtherTxObj);
> {code}
> In addition, the transaction manager must implement the Transaction object's {{hashCode}} method so that if two Transaction objects are equal, they have the same hash code. However, the converse is not necessarily true. Two Transaction objects with the same hash code are not necessarily equal.
> {quote}
> There are several transaction implementation classes in Narayana including:
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple}}
> * {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple}}
> Sometimes it comes to pass that, for whatever reason, importing a transaction might return a transaction instance of a different type than what was previously returned. In this case the flaw in the {{equals}} method is clear: it compares the types for effective equality before it compares the UID, causing two transactions of different types which refer to the same global transaction to be non-equal, which causes integrity checks in the remote JTA code to fail.
> I'll provide a PR that fixes the issue which you can use if you want.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months