[JBoss JIRA] Commented: (JBCACHE-629) SELECT FOR UPDATE semantics
by 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
19 years, 3 months
[JBoss JIRA] Closed: (JBCACHE-629) SELECT FOR UPDATE semantics
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-629?page=all ]
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: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months
[JBoss JIRA] Created: (JGRP-402) Simple Flow Control (SFC)
by Bela Ban (JIRA)
Simple Flow Control (SFC)
-------------------------
Key: JGRP-402
URL: http://jira.jboss.com/jira/browse/JGRP-402
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
SFC is a simple flow control protocol for group (= multipoint) messages.
Every sender has max_credits bytes for sending multicast messages to the group.
Every multicast message (we don't consider unicast messages) decrements max_credits by its size.
When max_credits falls below 0, the sender asks all receivers for new credits and blocks
until *all* credits have been received from all members.
When the receiver receives a credit request, it checks whether it has received max_credits bytes from the requester since
the last credit request. If yes, it sends new credits to the requester and resets the max_credits for the requester.
Else, it takes a note of the credit request from P and - when max_credits bytes have finally been received from P - it
sends the credits to P and resets max_credits for P.
The maximum amount of memory for received messages is therefore <number of senders> * max_credits.
The relationship with STABLE is as follows: when a member Q is slow, it will prevent STABLE from collecting messages above
the ones seen by Q (everybody else has seen more messages). However, because Q will *not* send credits back to the senders
until it has processed all messages worth max_credits bytes, the senders will block. This in turn allows STABLE to
progress and eventually garbage collect most messages from all senders. Therefore, SFC and STABLE complement each other,
with SFC blocking senders so that STABLE can catch up.
See doc/design/SimpleFlowControl.txt for details
--
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
19 years, 3 months