[JBoss JIRA] Updated: (JBCACHE-315) Break locks for state transfer
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-315?page=all ]
Manik Surtani updated JBCACHE-315:
----------------------------------
Fix Version/s: 2.1.0.CR1
> Break locks for state transfer
> ------------------------------
>
> Key: JBCACHE-315
> URL: http://jira.jboss.com/jira/browse/JBCACHE-315
> Project: JBoss Cache
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assigned To: Vladimir Blagojevic
> Priority: Critical
> Fix For: 2.1.0.GA, 2.1.0.CR1
>
>
> State transfer needs to acquire a lock on the root to make sure all existing TXs have been completed. However, when a TX takes more time than the lock acquisition timeout, state transfer will fail.
> Therefore, we need to forcefully acquire the locks for the state transfer by force-releasing the existing locks, and rolling back all TXs that held those locks.
> This will ensure that state transfer always succeeds, at the expense of some rolled back TXs.
> We need to investigate how this works with optimistic locking
--
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
18 years, 3 months
[JBoss JIRA] Created: (JBCACHE-1167) Heuristic outcome (STATUS_UNKNOWN) of transaction not handled properly
by Galder Zamarreno (JIRA)
Heuristic outcome (STATUS_UNKNOWN) of transaction not handled properly
----------------------------------------------------------------------
Key: JBCACHE-1167
URL: http://jira.jboss.com/jira/browse/JBCACHE-1167
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.4.1.SP4, 2.0.0.GA
Reporter: Galder Zamarreno
Assigned To: Manik Surtani
Fix For: 1.4.1.SP5
Where an XA transaction has a heuristic outcome, the status reported to
the afterCompletion synchronization is STATUS_UNKNOWN (5), since
JTA does not handle heuristics. In this case, the cache Synchronization
fails to rollback the cache tx. This leaves the app server in a bad (i.e. locked)
state even though the XA transaction has been resolved.
At first glance it looks like the afterCompletion synchronization should treat a
STATUS_UNKNOWN as a cause for rollback as well as logging the error as
they currently do. Unfortunately the fix may be more complex than that, since
the db may have committed rather than rolled back, meaning the cache would
be out of sync with the db if you rolled it back.
--
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
18 years, 3 months