[
http://jira.jboss.com/jira/browse/JBCACHE-70?page=comments#action_12402418 ]
Manik Surtani commented on JBCACHE-70:
--------------------------------------
The main driver for making it an XA resource is for us to not have the current workaround,
which is to actually commit state in the cache in the afterCompletion() callback. This is
actually incorrect since the transaction should have committed at this stage, and this
callback is only used to free up resources.
So the options are either:
1) Make JBC an XA resource
Easy, just implement XA interfaces and leave beforeCompletion() as is, but do
afterCompletion() stuff in separate commit() and rollback() callbacks. Also deal with
proper lock cleanup if recover() is called (map it to rollback()?)
2) Or try and work on a better 2PC system with Synchronizations?
* In beforeCompletion(), do the prepares AND commits, but HOLD ON to the locks.
* In afterCompletion() broadcast a cleanup call to release locks.
* Need to think about this because if afterCompletion() this fails we may end up with
stale locks.
The "usual" reason for wanting to make something an XA resource - i.e., to
handle recovery - doesn't apply to JBC since the state can never be recovered as the
cache is in memory. The best that can be done is for the state to be removed, i.e.,
cleaned up.
Make JBossCache an XAResource
-----------------------------
Key: JBCACHE-70
URL:
http://jira.jboss.com/jira/browse/JBCACHE-70
Project: JBoss Cache
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Manik Surtani
Fix For: 3.2.0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira