[ https://issues.jboss.org/browse/ISPN-994?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-994: ------------------------------- Description: now that ISPN-272 is implemented the TM is aware about the heuristic transactions. This is complementary to ISPN-272 and very important as without transaction failure cannot be fixed. After TM determines such a transaction it informs the System Administrator. It's SA's job to force the rollback/commit of those pending transactions. In order to do that he needs tooling in order to access the cluster. A solution would be JMX as described here: http://lists.jboss.org/pipermail/infinispan-dev/2011-March/007651.html was: now that ISPN-272 is implemented the TM is aware about the heuristic transactions. After TM determines such a transaction it informs the System Administrator. It's SA's job to force the rollback/commit of those pending transactions. In order to do that he needs tooling in order to access the cluster. A solution would be JMX as described here: http://lists.jboss.org/pipermail/infinispan-dev/2011-March/007651.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-994?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-994: ------------------------------- Fix Version/s: 5.0.0.FINAL -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ 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

[ https://issues.jboss.org/browse/ISPN-994?page=com.atlassian.jira.plugin.s... ] Mircea Markus commented on ISPN-994: ------------------------------------ re:restarting is solved by view id. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-994?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-994: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/254 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-994?page=com.atlassian.jira.plugin.s... ] Mircea Markus resolved ISPN-994. -------------------------------- Resolution: Done -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira