[jira] Commented: (GERONIMO-4184) In-doubt transaction Id's could be reused during server startup

2011-03-16 Thread David Jencks (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007792#comment-13007792
 ] 

David Jencks commented on GERONIMO-4184:


I think this patch will break recovery.  The first 8 bytes of the byte arrays 
in the xid are a long counter, the rest is the tmid.  Recovery needs to be able 
to determine if an xid coming back from an XAResource came from this tm.  It 
does this by matching the bytes after 8 in the global xid with the baseid in 
the XidFactory.  If the base id is different every time you start the tm, 
there's no way to determine if a branch that has been prepared on an XAResource 
but not recorded in the tm log came from this tm.

I think the problem here is that our documentation is not sufficiently 
insistent that you NEED to configure multiple geronimo servers using the same 
RM with DIFFERENT tmids.

As long as the above is followed, we could randomize the most significant 2 
bytes of the long counter.  However I think it would be better to track the 
counter persistently such as by reserving blocks of say 1024 ids and recording 
this persistently either in a log record or in a separate file.

 In-doubt transaction Id's could be reused during server startup
 ---

 Key: GERONIMO-4184
 URL: https://issues.apache.org/jira/browse/GERONIMO-4184
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: transaction manager
Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.4
Reporter: Kevan Miller
 Fix For: Wish List

 Attachments: GERONIM-4184.patch


 During server restart, we may reuse an Xid for a transaction which is 
 in-doubt. Potentially confusing a resource manager. We need to insure this 
 does not occur. Simple way is to remember the largest Xid in tran log and 
 start with a larger number. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Commented: (GERONIMO-4184) In-doubt transaction Id's could be reused during server startup

2011-03-16 Thread Vamsavardhana Reddy (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007817#comment-13007817
 ] 

Vamsavardhana Reddy commented on GERONIMO-4184:
---

Thanks David. The one doubt I had is if introducing two random bytes along with 
tmId would break anything. Your comment has clarified that.

Essentially the random bytes introduced by fix for GERONIMO-4393 will result in 
a different tmId each time the server is started and break transaction 
recovery. (Geronimo server may be immune to this as we use the XidFactoryImpl 
constructor with tmId as parameter.)  How can we make sure that even the 
generated tmId would be the same for a server instance with subsequent restarts?

 In-doubt transaction Id's could be reused during server startup
 ---

 Key: GERONIMO-4184
 URL: https://issues.apache.org/jira/browse/GERONIMO-4184
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: transaction manager
Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.4
Reporter: Kevan Miller
 Fix For: Wish List

 Attachments: GERONIM-4184.patch


 During server restart, we may reuse an Xid for a transaction which is 
 in-doubt. Potentially confusing a resource manager. We need to insure this 
 does not occur. Simple way is to remember the largest Xid in tran log and 
 start with a larger number. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Commented: (GERONIMO-4184) In-doubt transaction Id's could be reused during server startup

2011-03-16 Thread David Jencks (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007821#comment-13007821
 ] 

David Jencks commented on GERONIMO-4184:


The no-arg constructor is only there for people who don't care about recovery 
and can't be bothered to set up the tm properly.

I guess if we're going to do anything here we should figure out a way to store 
the baseid and counter range in the tx log (in the log object, not necessarily 
in the log files) and read them in as part of recovery.  Then if there's a 
recorded baseid we can use it.  


 In-doubt transaction Id's could be reused during server startup
 ---

 Key: GERONIMO-4184
 URL: https://issues.apache.org/jira/browse/GERONIMO-4184
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: transaction manager
Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.4
Reporter: Kevan Miller
 Fix For: Wish List

 Attachments: GERONIM-4184.patch


 During server restart, we may reuse an Xid for a transaction which is 
 in-doubt. Potentially confusing a resource manager. We need to insure this 
 does not occur. Simple way is to remember the largest Xid in tran log and 
 start with a larger number. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Commented: (GERONIMO-4184) In-doubt transaction Id's could be reused during server startup

2011-03-15 Thread Vamsavardhana Reddy (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13006815#comment-13006815
 ] 

Vamsavardhana Reddy commented on GERONIMO-4184:
---

GERONIMO-4393 has introduced two random bytes into the baseId to avoid 
duplication of baseId across multiple JVMs on the same machine.  That fix would 
still not suffice completely as the two random bytes are added to baseId only 
if the no-argument constructor of XidFactoryImpl is used and Geronimo uses the 
other constructor that takes byte[] tmId as argument.  If we add two random 
bytes to baseId even in the case of the constructor with tmId, we can minimize 
the chance of reuse of In-doubt transaction Id's as the baseId would be 
different on each run of the server. We can even increase the length of random 
bytes (to say 4 instead of 2) to further reduce the chance of reuse of In-doubt 
transaction Id's.  Any suggestions or comments to this approach?

 In-doubt transaction Id's could be reused during server startup
 ---

 Key: GERONIMO-4184
 URL: https://issues.apache.org/jira/browse/GERONIMO-4184
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: transaction manager
Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.4
Reporter: Kevan Miller
 Fix For: Wish List


 During server restart, we may reuse an Xid for a transaction which is 
 in-doubt. Potentially confusing a resource manager. We need to insure this 
 does not occur. Simple way is to remember the largest Xid in tran log and 
 start with a larger number. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira