[jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-406) Improve handling of method calls that are queued during region activation

[Vladimir Blagojevic (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBCACHE-406?page=all ]

Vladimir Blagojevic resolved JBCACHE-406.
-----------------------------------------

       Resolution: Done
    Fix Version/s:     (was: 2.1.0.GA)
                   2.0.0.GA

With introduction of FLUSH in all JBC state transfers this task becomes obsolete.

> Improve handling of method calls that are queued during region activation
> -------------------------------------------------------------------------
>
>                 Key: JBCACHE-406
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-406
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.2.4SP1, 1.2.4
>            Reporter: Brian Stansberry
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.0.0.GA
>
>
> During a call to activateRegion(), any incoming replication messages related to the relevant region are queued (i.e. stored in a list) and then invoked once the region's state has been received and integrated. Doing this, in the case of prepare() messages, violates transactional integrity, since the activating cache responds positively after queuing the prepare(), and only finds out later whether the prepare() can actually succeed.  So, we need to optimize the queuing process to give the greatest likelihood that any received prepare calls will in fact succeed.  Fundamentally, we want to arrange the queue so that any commit() message immediately follows its related prepare, thus reducing the likelihood that a subsequent prepare will not be able to succeed due to conflicts with the preceding prepare's locks.
> When a new commit()/rollback method call is received:
> 1) Iterator through the existing queued calls, looking for a prepare() associated with the same gtx.
> 2) If a prepare is found, and the new message is a commit, place the commit in the queue immediately after the prepare.
> 3) If a prepare is found, and the new message is a rollback, remove the prepare from the queue.
> 4) If no prepare is found, discard the commit or rollback; there is no point later executing a commit/rollback if the prepare has not been executed.

-- 
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