[JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-2264:
-----------------------------------
Tom, great write up. I suggest changing this issue from a bug to something else (feature request?)
> Error enlisting second xa resource on the same oracle instance but other schema
> -------------------------------------------------------------------------------
>
> Key: JBTM-2264
> URL: https://issues.jboss.org/browse/JBTM-2264
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 5.0.3
> Reporter: Evgeniy Smelik
> Assignee: Tom Jenkinson
> Attachments: sscce.zip, sscce.zip, test.log
>
>
> I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema.
> Whole stack trace:
> {noformat}
> oracle.jdbc.xa.OracleXAException
> at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110)
> at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179)
> at SimpleJdbcTest.insert(SimpleJdbcTest.java:46)
> at SimpleJdbcTest.main(SimpleJdbcTest.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed
> at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179)
> at SimpleJdbcTest.insert(SimpleJdbcTest.java:46)
> at SimpleJdbcTest.main(SimpleJdbcTest.java:36)
> {noformat}
> (Detail log and SSCCE are attached).
> I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances.
> I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not.
> I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-...].
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2264:
-------------------------------------
I should also mention, there is something strange that happens with Oracle when the patch is applied (I checked it affects BTM too). You can replicate the issue with the following raw XA and SQL code:
{code}
final OracleXADataSource xaDataSource1 = new OracleXADataSource();
((OracleXADataSource) xaDataSource1).setNetworkProtocol("tcp");
((OracleXADataSource) xaDataSource1).setServerName(DB_HOST);
((OracleXADataSource) xaDataSource1).setPortNumber(1521);
((OracleXADataSource) xaDataSource1).setDatabaseName(DB_SID);
((OracleXADataSource) xaDataSource1).setDriverType("thin");
((OracleXADataSource) xaDataSource1).setUser(DB_USER1);
((OracleXADataSource) xaDataSource1).setPassword(DB_USER1);
final OracleXADataSource xaDataSource2 = new OracleXADataSource();
((OracleXADataSource) xaDataSource2).setNetworkProtocol("tcp");
((OracleXADataSource) xaDataSource2).setServerName(DB_HOST);
((OracleXADataSource) xaDataSource2).setPortNumber(1521);
((OracleXADataSource) xaDataSource2).setDatabaseName(DB_SID);
((OracleXADataSource) xaDataSource2).setDriverType("thin");
((OracleXADataSource) xaDataSource2).setUser(DB_USER2);
((OracleXADataSource) xaDataSource2).setPassword(DB_USER2);
XAConnection xaConnection1 = xaDataSource1.getXAConnection();
XAResource xaResource1 = new IsSameRMOverrideXAResource(
xaConnection1.getXAResource());
Connection connection1 = xaConnection1.getConnection();
XAConnection xaConnection2 = xaDataSource2.getXAConnection();
Uid gtrid = new Uid();
XidImple xid1 = new XidImple(gtrid, true, 1);
xaResource1.start(xid1, XAResource.TMNOFLAGS);
PreparedStatement preparedStatement1 = connection1
.prepareStatement("INSERT INTO jta_test (some_string) VALUES ('test')");
preparedStatement1.execute();
System.out.println(xaResource1 + " sql for " + xaConnection1);
XAResource xaResource2 = new IsSameRMOverrideXAResource(
xaConnection2.getXAResource());
Connection connection2 = xaConnection2.getConnection();
XidImple xid2 = new XidImple(gtrid, true, 1);
xaResource2.start(xid2, XAResource.TMNOFLAGS);
PreparedStatement preparedStatement2 = connection2
.prepareStatement("INSERT INTO jta_test (some_string) VALUES ('test')");
System.out.println(xaResource2 + " sql for " + xaConnection2);
preparedStatement2.execute();
xaResource1.end(xid1, XAResource.TMSUCCESS);
int prepare1 = xaResource1.prepare(xid1);
xaResource2.end(xid2, XAResource.TMSUCCESS);
int prepare2 = xaResource2.prepare(xid2);
if (prepare1 != XAResource.XA_RDONLY) xaResource1.rollback(xid1);
if (prepare2 != XAResource.XA_RDONLY) xaResource2.rollback(xid2);
{code}
That first prepare returns XAResource.XA_RDONLY. If you alter the code to use a different gtrid for each branch the resource manager returns XA_OK as expected (but obviously that is not what happens when the TM is involved as the gtrid is fixed for the TX). It appears that internally Oracle may be optimizing the SQL into the second prepare as when I reordered the prepare calls xid2 instead returned XA_RDONLY. It might be a setting on our database I am not sure. Either way you should verify that the app is performing the updates that you expect.
> Error enlisting second xa resource on the same oracle instance but other schema
> -------------------------------------------------------------------------------
>
> Key: JBTM-2264
> URL: https://issues.jboss.org/browse/JBTM-2264
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 5.0.3
> Reporter: Evgeniy Smelik
> Assignee: Tom Jenkinson
> Attachments: sscce.zip, sscce.zip, test.log
>
>
> I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema.
> Whole stack trace:
> {noformat}
> oracle.jdbc.xa.OracleXAException
> at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110)
> at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179)
> at SimpleJdbcTest.insert(SimpleJdbcTest.java:46)
> at SimpleJdbcTest.main(SimpleJdbcTest.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed
> at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179)
> at SimpleJdbcTest.insert(SimpleJdbcTest.java:46)
> at SimpleJdbcTest.main(SimpleJdbcTest.java:36)
> {noformat}
> (Detail log and SSCCE are attached).
> I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances.
> I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not.
> I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-...].
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2264:
-------------------------------------
Hi Evgeniy,
I have raised a pull request for this in our transactional driver code. I have also deployed a snapshot version of Narayana with the change already in there for you to have a go with. I have tested it locally (extensively) and it works for me. I can see the SNAPSHOT over here: https://repository.jboss.org/nexus/content/groups/public/org/jboss/naraya.... All you should need to do is change your pom to this version.
Now for some background. BTM and Atomikos are not strictly spec compliant in my mind as their core transaction processing engine performs simple pointer comparison to determine if two XAResources are equivalent rather than the spec defined approach of using isSameRM. You can see the pointer comparison for yourself over here: https://github.com/bitronix/btm/blob/master/btm/src/main/java/bitronix/tm...
You can see where the spec has pseudo code that demonstrates how the transaction manager is intended to use isSameRM in section "3.4.9 Identifying Resource Manager Instance" over here: https://jcp.org/en/jsr/detail?id=907
If two XAR are not equivalent you are meant to generate a new Xid for the branch and call start with TMNOFLAGS (as BTM/Atomikos will in this case, even though its technically the same RM) and if they are equivalent you use the same Xid and call start with TMJOIN (as we do).
It turns out that there are a number of resource managers that return true to isSameRM but cannot handle the TMJOIN flag. It also turns out that this is a known issue with some of the drivers and Ironjacamar (Red Hats JCA implementation in Wildfly) already works around that for a number of drivers by wrapping their XAResources with an is-same-rm-override flag that returns false. The impact of this is that although your test would work in WildFly, there is a slight performance impact as the RM has two branches, plus should you touch the same tables you may be able to deadlock. Anyway, as you were using transactional driver rather than ironjacamar you have hit this issue. I have effectively backported that IJ workaround for a number of drivers which are also not compliant to our transactional driver code.
The reason we haven't gone to pointer comparison is:
1. Spec compliance - we don't break that
2. There is an issue with overriding isSameRM which affects app servers performing a process known as transaction inflow. Due to limitations with the transaction inflow API (discussed at length elsewhere, for example https://issues.jboss.org/browse/JBTM-622) a transaction manager is not permitted to generate different Xids for resources. As such if we override the same rm report from the RM, RMs which correctly implement isSameRM and accept TMJOIN would be unfairly penalised as they would get:
{code}
xaResource1.start(xid1, TMNOFLAGS)
xaResource2.start(xid1, TMNOFLAGS)
{code}
Which is a protocol error.
Hope it helps,
Tom
> Error enlisting second xa resource on the same oracle instance but other schema
> -------------------------------------------------------------------------------
>
> Key: JBTM-2264
> URL: https://issues.jboss.org/browse/JBTM-2264
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 5.0.3
> Reporter: Evgeniy Smelik
> Assignee: Tom Jenkinson
> Attachments: sscce.zip, sscce.zip, test.log
>
>
> I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema.
> Whole stack trace:
> {noformat}
> oracle.jdbc.xa.OracleXAException
> at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110)
> at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179)
> at SimpleJdbcTest.insert(SimpleJdbcTest.java:46)
> at SimpleJdbcTest.main(SimpleJdbcTest.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed
> at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179)
> at SimpleJdbcTest.insert(SimpleJdbcTest.java:46)
> at SimpleJdbcTest.main(SimpleJdbcTest.java:36)
> {noformat}
> (Detail log and SSCCE are attached).
> I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances.
> I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not.
> I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-...].
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2264:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/737
> Error enlisting second xa resource on the same oracle instance but other schema
> -------------------------------------------------------------------------------
>
> Key: JBTM-2264
> URL: https://issues.jboss.org/browse/JBTM-2264
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 5.0.3
> Reporter: Evgeniy Smelik
> Assignee: Tom Jenkinson
> Attachments: sscce.zip, sscce.zip, test.log
>
>
> I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema.
> Whole stack trace:
> {noformat}
> oracle.jdbc.xa.OracleXAException
> at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110)
> at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179)
> at SimpleJdbcTest.insert(SimpleJdbcTest.java:46)
> at SimpleJdbcTest.main(SimpleJdbcTest.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed
> at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003)
> at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179)
> at SimpleJdbcTest.insert(SimpleJdbcTest.java:46)
> at SimpleJdbcTest.main(SimpleJdbcTest.java:36)
> {noformat}
> (Detail log and SSCCE are attached).
> I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances.
> I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not.
> I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-...].
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (JBTM-622) Support for crash recovery of tx-inflow with multiple resource managers
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-622?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson updated JBTM-622:
-------------------------------
Forum Reference: https://developer.jboss.org/thread/202512
> Support for crash recovery of tx-inflow with multiple resource managers
> -----------------------------------------------------------------------
>
> Key: JBTM-622
> URL: https://issues.jboss.org/browse/JBTM-622
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: JCA, Recovery, Transaction Core
> Affects Versions: 4.2.3.CP06
> Reporter: Toshiya Kobayashi
> Priority: Minor
> Fix For: 6.0.0
>
>
> JCA tx-inflow spec allows the external EIS to provide the Xid for the inflowed transaction. The TM handling the inflowed (i.e. subordinate) transaction uses this Xid verbatim when talking to RMs.
> In current implementation, each RM enlisted in the subordinate tx will see the same Xid as originally provided by the EIS. This screws recovery where multiple resources are involved, since a given Xid no longer belongs to exactly one RM, but may be shared by several. We can no longer return a single XAResource to drive the recovery for a given Xid.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (JBTM-2266) TransactionReaper is using currentTimeMillis for timeout calculation
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBTM-2266?page=com.atlassian.jira.plugin.... ]
David Lloyd updated JBTM-2266:
------------------------------
Issue Type: Enhancement (was: Bug)
> TransactionReaper is using currentTimeMillis for timeout calculation
> --------------------------------------------------------------------
>
> Key: JBTM-2266
> URL: https://issues.jboss.org/browse/JBTM-2266
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Affects Versions: 5.0.3
> Reporter: David Lloyd
> Assignee: Tom Jenkinson
> Priority: Minor
>
> Noticed while browsing through some code that the TransactionReaper uses currentTimeMillis() to calculate timeouts. However the timestamp reported by this method can change in an unexpected way if the system clock is changed.
> An artificial clock based on System.nanoTime() should be used instead, since while this time may vary slightly between cores, in general it will be highly accurate and, most importantly, monotonic and steady (and unaffected by changes to the system time).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (JBTM-2266) TransactionReaper is using currentTimeMillis for timeout calculation
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2266?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-2266:
-----------------------------------
I'm not sure this really needs to be changed. This isn't a hard realtime deadline. The standards (JTA, OTS/JTS) don't require the timeout to kick in *exactly* on time. So some skew is fine. As a result I wouldn't even classify the current implementation as a bug.
> TransactionReaper is using currentTimeMillis for timeout calculation
> --------------------------------------------------------------------
>
> Key: JBTM-2266
> URL: https://issues.jboss.org/browse/JBTM-2266
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 5.0.3
> Reporter: David Lloyd
> Assignee: Tom Jenkinson
> Priority: Minor
>
> Noticed while browsing through some code that the TransactionReaper uses currentTimeMillis() to calculate timeouts. However the timestamp reported by this method can change in an unexpected way if the system clock is changed.
> An artificial clock based on System.nanoTime() should be used instead, since while this time may vary slightly between cores, in general it will be highly accurate and, most importantly, monotonic and steady (and unaffected by changes to the system time).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (JBTM-2266) TransactionReaper is using currentTimeMillis for timeout calculation
by David Lloyd (JIRA)
David Lloyd created JBTM-2266:
---------------------------------
Summary: TransactionReaper is using currentTimeMillis for timeout calculation
Key: JBTM-2266
URL: https://issues.jboss.org/browse/JBTM-2266
Project: JBoss Transaction Manager
Issue Type: Bug
Affects Versions: 5.0.3
Reporter: David Lloyd
Assignee: Tom Jenkinson
Priority: Minor
Noticed while browsing through some code that the TransactionReaper uses currentTimeMillis() to calculate timeouts. However this method can change if the system time has changed.
An artificial clock based on System.nanoTime() should be used instead, since while this time may vary slightly between cores, in general it will be highly accurate and, most importantly, monotonic and steady (and unaffected by changes to the system time).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months
[JBoss JIRA] (JBTM-2266) TransactionReaper is using currentTimeMillis for timeout calculation
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBTM-2266?page=com.atlassian.jira.plugin.... ]
David Lloyd updated JBTM-2266:
------------------------------
Description:
Noticed while browsing through some code that the TransactionReaper uses currentTimeMillis() to calculate timeouts. However the timestamp reported by this method can change in an unexpected way if the system clock is changed.
An artificial clock based on System.nanoTime() should be used instead, since while this time may vary slightly between cores, in general it will be highly accurate and, most importantly, monotonic and steady (and unaffected by changes to the system time).
was:
Noticed while browsing through some code that the TransactionReaper uses currentTimeMillis() to calculate timeouts. However this method can change if the system time has changed.
An artificial clock based on System.nanoTime() should be used instead, since while this time may vary slightly between cores, in general it will be highly accurate and, most importantly, monotonic and steady (and unaffected by changes to the system time).
> TransactionReaper is using currentTimeMillis for timeout calculation
> --------------------------------------------------------------------
>
> Key: JBTM-2266
> URL: https://issues.jboss.org/browse/JBTM-2266
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 5.0.3
> Reporter: David Lloyd
> Assignee: Tom Jenkinson
> Priority: Minor
>
> Noticed while browsing through some code that the TransactionReaper uses currentTimeMillis() to calculate timeouts. However the timestamp reported by this method can change in an unexpected way if the system clock is changed.
> An artificial clock based on System.nanoTime() should be used instead, since while this time may vary slightly between cores, in general it will be highly accurate and, most importantly, monotonic and steady (and unaffected by changes to the system time).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 6 months