[infinispan-issues] [JBoss JIRA] Commented: (ISPN-777) Eager cluster wide locks not cleaned upon rollback

Mircea Markus (JIRA) jira-events at lists.jboss.org
Mon Nov 22 08:24:53 EST 2010


    [ https://jira.jboss.org/browse/ISPN-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564550#comment-12564550 ] 

Mircea Markus commented on ISPN-777:
------------------------------------

Another solution from bela:


bela
Before a TX acquires locks, it should check if its owner is still in the current view
If not, the TX would be released
This way, even of T2 runs after T1, T1 would commit suicide

13:17
mmarkus
bela: yes. but this would be an check-then-act that should be guarded with a lock

13:17
bela
and roll itself back - because it is not in the current view instaled by T1
OK, so T1 and T2 access the TX table
You guarantee serialized access through a lock
So it's either T1 --> T2, or T2 --> T1
T2 first cleans up running TXs and the view is already set
T1 then sees that it is not in the current view and rolls back itself
or
T1 sees that it's in the current view and proceeds
T2 the cleans it up

13:20
mmarkus
that would work as well.

13:20
bela
I'd give it a simple try, seems easier than the prev solution

13:21
mmarkus
So i would need to have a single thread working on behalf of a transaction at a time
bela: which I think it makes sense
bela: +1.


> Eager cluster wide locks not cleaned upon rollback
> --------------------------------------------------
>
>                 Key: ISPN-777
>                 URL: https://jira.jboss.org/browse/ISPN-777
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Locking and Concurrency
>    Affects Versions: 4.2.0.BETA1
>            Reporter: Vladimir Blagojevic
>            Assignee: Mircea Markus
>            Priority: Blocker
>             Fix For: 4.2.0.CR1
>
>         Attachments: CacheScheduledCounter.java, ISPN-777_output.txt
>
>
> It seems that rollback sometimes does not release acquired eager locks. See attached test program and run two JVM instances on the same machine. Program schedules a task to run every 5 seconds. Tasks simply locks a key, gets the value, increases the value and puts it back surrounded by begin/commit/rollback tx boundary. 
> Steps to reproduce (keep repeating steps until problem is encountered):
> 1) Kill one running instance. 
> 2) Restart it
> See attached example output of a run. 

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the infinispan-issues mailing list