[infinispan-issues] [JBoss JIRA] Commented: (ISPN-994) Crete tooling (JMX) to handle heuristic transactions

[ https://issues.jboss.org/browse/ISPN-994?page=com.atlassian.jira.plugin.s... ] Mircea Markus commented on ISPN-994: ------------------------------------ It is rather difficult to pass the XID (as received from TM's recover process) to ISPN's JMX operations: the XID is primarily an byte[]; converting a String to a byte[] is difficult due to encodings. In order to avoid this: - have an operation shows the mapping XID->internal value (e.g. internal value might be a long) - the sys admin visually maps XID to the internal value - it calls forceCommit(long)/forceRollback(long) This is not very user friendly but still easier than coming up with a XID based version. On top of that, the XID based operations are still exposed (i.e. forceCommit(XID)/forceRollback(XID)), as applications might want to access them programatically). This solution requires generating a cluster wide unique long for each transaction/XID. AFAIK we have something similar for HR unique ids that can be reused. On the top of my head a way to generate such a unique long is: - on each node have a shared static counter that increments for each new tx (long) - replace the most relevant decimal digit from the long with the viewId - replace the 2nd most relevant digit from the long with the node's index -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira