[jboss-jira] [JBoss JIRA] Commented: (JBCACHE-629) SELECT FOR UPDATE semantics

[Manik Surtani (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBCACHE-629?page=comments#action_12350456 ] 
            
Manik Surtani commented on JBCACHE-629:
---------------------------------------

Fixed in CVS HEAD, will be in BETA1.

See o.j.c.options.ForceWriteLockTest for usage details.

> SELECT FOR UPDATE semantics
> ---------------------------
>
>                 Key: JBCACHE-629
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-629
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0.GA, 2.0.0.BETA1
>
>
> An API with semantics similar to a database SELECT FOR UPDATE would be useful -- e.g. getForUpdate(...) which acts like a get, but acquires a WL instead of a RL.
> Example situation:
> IsolationLevel is READ_COMMITTED
> - Two threads A and B.
> 1. Thread A starts a new Transaction.
> 2. Thread A calls get(Fqn for x, key for  x)
> 3. Thread A modifies Object x (e.g x.setFoo("bar")).
> 4. Thread B calls get(Fqn for x, key for Object x)
> 5. Thread B calls x.getFoo()
> 6. Thread A calls put(Fqn for x, key for x, x);
> 7. Thread A rolls back the Transaction. 
> Problem is in Step 5 Thread B sees uncommitted data, because the WL on the cache node is not acquired until Step 6.  Only way to control this is for Thread A to synchronize on x and write x in such a way that access to all properties like Foo are synchronized.
> With getForUpdate, A would acquire the WL in step 1, thus blocking B from reading until the A's TX commits.

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