Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-272

Implement XA recovery in TransactionXaAdapter

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

XMLWordPrintable

    • Medium

      We currently don't support any sort of recovery from transaction failures.
      E.g.
      tm.start();
      database.delete(account);
      ispnCache.put(account);
      tm.commit():
      At tm commit:
      -prepare is successful on both enlisted resources.

      • database.commit - fails
        What shall we do with the locks/state from ispnCache.
        Possible solutions:
      • configure to automatically commit/rollback after a timeout
      • keep locks on resources and allow manual intervention through JMX
      • others?

            [ISPN-272] Implement XA recovery in TransactionXaAdapter

            Mircea Markus (Inactive) added a comment -

            Another Jira was created to add tooling to support recovery:
            ISPN-994 - Crete tooling (JMX) to handle heuristic transactions

            Mircea Markus (Inactive) added a comment - Another Jira was created to add tooling to support recovery: ISPN-994 - Crete tooling (JMX) to handle heuristic transactions

            Mircea Markus (Inactive) added a comment -

            re: whilst at this also fix this todo - // TODO Couldn't affected keys be derived from modifications?
            no, it can't, as eager locks are not reflected by the modifications.

            Mircea Markus (Inactive) added a comment - re: whilst at this also fix this todo - // TODO Couldn't affected keys be derived from modifications? no, it can't, as eager locks are not reflected by the modifications.

            Mircea Markus (Inactive) added a comment -

            whilst at this also fix this todo - // TODO Couldn't affected keys be derived from modifications?

            Mircea Markus (Inactive) added a comment - whilst at this also fix this todo - // TODO Couldn't affected keys be derived from modifications?

            Mircea Markus (Inactive) added a comment -

            Update the log message in TransactionXAAdapter: http://community.jboss.org/message/581125#581125

            Mircea Markus (Inactive) added a comment - Update the log message in TransactionXAAdapter: http://community.jboss.org/message/581125#581125

            Manik Surtani (Inactive) added a comment -

            Yup. See the email thread I posted - it has details.

            Manik Surtani (Inactive) added a comment - Yup. See the email thread I posted - it has details.

            Mircea Markus (Inactive) added a comment -

            @Manik
            TransactionXaAdapter.recover method as defined by JTA spec does not DO recovery but only lets the TM know about which transactions are prepared or heuristically committed. Not sure this is the way to go here.

            Mircea Markus (Inactive) added a comment - @Manik TransactionXaAdapter.recover method as defined by JTA spec does not DO recovery but only lets the TM know about which transactions are prepared or heuristically committed. Not sure this is the way to go here.

            Manik Surtani (Inactive) added a comment -

            Also, Infinispan not responding to recover() properly can cause other resources in a distributed transaction to fail or behave incorrectly. See this mail list thread for details.

            http://lists.jboss.org/pipermail/infinispan-dev/2010-December/007026.html

            Look at (1) outlined in the email above.

            Manik Surtani (Inactive) added a comment - Also, Infinispan not responding to recover() properly can cause other resources in a distributed transaction to fail or behave incorrectly. See this mail list thread for details. http://lists.jboss.org/pipermail/infinispan-dev/2010-December/007026.html Look at (1) outlined in the email above.

            Manik Surtani (Inactive) added a comment -

            Some more comments.

            Currently, TransactionXaAdapter.recover() is a no-op. It should:

            1) Stop the cache (prevent any more txs from starting)
            2) Roll back existing txs
            3) Release any locks
            4) Wipe in-memory state
            5) Restart the node so it re-joins the cluster and gets a fresh copy of state

            Manik Surtani (Inactive) added a comment - Some more comments. Currently, TransactionXaAdapter.recover() is a no-op. It should: 1) Stop the cache (prevent any more txs from starting) 2) Roll back existing txs 3) Release any locks 4) Wipe in-memory state 5) Restart the node so it re-joins the cluster and gets a fresh copy of state

            Galder Zamarreño added a comment -

            Jeff, that comment has been clarified in the user forums before: http://community.jboss.org/message/518367#518367

            Galder Zamarreño added a comment - Jeff, that comment has been clarified in the user forums before: http://community.jboss.org/message/518367#518367

            Jeff Nadler (Inactive) added a comment -

            There is some interesting commentary here about using Bitronix with Infinispan, it seems that they are having some troubles due to missing API in Infinispan: http://markmail.org/thread/oqruq7ohdzqcktxw#query:+page:1+mid:oqruq7ohdzqcktxw+state:results

            Jeff Nadler (Inactive) added a comment - There is some interesting commentary here about using Bitronix with Infinispan, it seems that they are having some troubles due to missing API in Infinispan: http://markmail.org/thread/oqruq7ohdzqcktxw#query:+page:1+mid:oqruq7ohdzqcktxw+state:results

              mircea.markus Mircea Markus (Inactive)
              mircea.markus Mircea Markus (Inactive)
              Archiver:
              rhn-support-adongare Amol Dongare

                Created:
                Updated:
                Resolved:
                Archived: