A basic question about concurrency

[fatefree]

Our app is using the default level of concurreny (REPEATABLE_READ) but we are experiencing lock acquisition timeouts, and I believe this level of concurrency is higher than our app requires.

Our app does not update or modify any element at all once it is put in cache, it only puts an element in (it expires after a time using the ExpirationPolicy) and it may be read multiple times.

What level of concurrency would best suite this kind of application, while ensuring that cache can only read an element once it is fully put inside the cache?

[fatefree]

Also I should mention that this cache is currently being replicated across two machines, possibly more in the future

[manik]

READ_COMMITTED would still be safe, you could also increase your lock acquisition timeout.

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

[manik]

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?

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

[manik]

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.