]
Manik Surtani closed JBCACHE-629.
---------------------------------
Resolution: Done
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.BETA1, 2.0.0.GA
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: