[jira] Created: (RIVER-105) Support the resolution of orphaned transactions

["Frank Barnaby (JIRA)" <ji...@apache.org>]

Support the resolution of orphaned transactions
-----------------------------------------------

                 Key: RIVER-105
                 URL: https://issues.apache.org/jira/browse/RIVER-105
             Project: River
          Issue Type: Improvement
          Components: com_sun_jini_outrigger
    Affects Versions: jtsk_1.1
            Reporter: Frank Barnaby
            Priority: Minor


Bugtraq ID [5040164|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5040164]

Once Outrigger has voted to commit a transaction it must hold on to that transaction (and any associated locks) until the {{TransactionManager}} makes an abort or commit call. If the {{TransactionManager}} has permanently crashed this could be a very long time. In effect the transaction has become "orphaned" and Outrigger will be left holding onto it, and the associated locks, forever.

We should provide some administrative process for resolving (e.g. forcing a commit or abort) orphaned transactions. It may end up just being documentation, but it will likely require adding features to Outrigger.

*Comments*
Seems unlikely that one would actually get orphaned transactions. The {{TransactionManager}} has to crash in such a way it can't be recovered, there has to be multiple participants (can't get an orphaned transaction with {{prepareAndCommit}}), and the manager has to crash during a relatively small window. Having said that there does seem to be a completeness issue here.

*Suggested Fix*
Possible ideas:

1] When joining a transaction record the result of {{toString}} on the manager. Add an admin method that returns a list of prepared unresolved transactions. Each item in the list will have three items :

   - A space specific id for the transaction
   - The result of calling {{toString()}} on the transaction's manager
   - The transaction's id

Add a second admin method that will take the space specific id and abort or commit (caller's choice) the transaction. The usage model would be that a admin could call the first method. Use the string to correlate the space specific id's to the failed transaction manager, and then use the second method to resolve the orphaned transactions. (note, Mahalo's proxy does not currently have a useful {{toString}}, however, {{getReferentUuid}} could also work - might want to use both)

2] Add a method that would abort (or commit, caller's choice?) any prepared transaction that had been in that state for more than some threshold value (caller specified?). Would give the admin less control (couldn't abort some transactions while committing others, thought I am not sure how useful this would be in practice), but is a bit simpler and might not require changes to Outrigger's persist store.

3] Blanket timeout on all voted transactions set in configuration.




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.