-
1. Re: A basic question about concurrency
fatefree Apr 1, 2008 9:15 AM (in response to fatefree)Also I should mention that this cache is currently being replicated across two machines, possibly more in the future
-
2. Re: A basic question about concurrency
manik Apr 2, 2008 5:46 AM (in response to fatefree)READ_COMMITTED would still be safe, you could also increase your lock acquisition timeout.
-
3. Re: A basic question about concurrency
fatefree Apr 2, 2008 9:08 AM (in response to fatefree)Well the timeout is 15 seconds already so I'd rather not increase it any more. What could potentially happen if I use read_uncommitted? Is there any potential problem since I don't update any object in cache? Could it even be None for the isolation level, or would that mean even gets and puts could cause trouble?
-
4. Re: A basic question about concurrency
manik Apr 2, 2008 10:43 AM (in response to fatefree)I wouldn't use READ_UNCOMMITTED - you could end up attempting a read of a node before it has been completely written. Would a node ever be removed?
-
5. Re: A basic question about concurrency
fatefree Apr 2, 2008 1:03 PM (in response to fatefree)Yeah a node can be removed through an expiration policy, every 30 minutes or so.
Theres only one string stored in the node, so you are saying its possible that we may read only half of the string with read_uncommited? -
6. Re: A basic question about concurrency
manik Apr 14, 2008 7:20 PM (in response to fatefree)You could try READ_UNCOMMITTED, but you ought to make sure you thoroughly stress test things in a test environment first. :-) It just may be that your access pattern won't cause any problems, but there are no guarantees here.