2

If two transactions (both at RR isolation level) ask for the same item which is 2nd-level cached, and then they modify and store this item. Now, for reading that item, they did not run any SQL because it's cached; so in this case, will they actually start a data base transaction? And when they commit their changes, will they run into lost update problem?

shrini1000
  • 7,038
  • 12
  • 59
  • 99

1 Answers1

1

From a pessimistic point of view:

If the second level cache is configured to participate in the transaction, then only the one that first acquired the write lock would be able to modify the cached object, and then write the change to the database. When the second transaction wants to acquire the write lock, it would have to wait until the first transaction ends and releases it.

With optimistic locking, I guess a Concurrent Modification Exception (or similar name) should happen and the second transaction would retry the operation.

Luciano
  • 8,552
  • 5
  • 32
  • 56
  • Let's say the cache is read-write. The transactions won't obtain shared read locks in DB because they'd never go to DB to read. Let's say t1 updates first, so it locks the object, gets a DB write lock, updates the DB and releases the DB write lock and the object lock; t2 then locks the object, gets DB write lock, updates the DB and releases the DB write lock and object lock. So won't t2 overwrite t1's changes? So won't we get a lost update even though the isolation level is RR? – shrini1000 Apr 05 '12 at 16:45
  • In the example you mention, t1 writes first and then t2. The Lost Update problem happens when t2 writes after having read the value BEFORE t1 changed it. In your example, no transaction reads anything, they only write. If t2 had read the value before t1 updates it, then t1 would not be able to do the update because t2 has a read lock. And the write lock cannot be shared with a read lock. – Luciano Apr 05 '12 at 17:21
  • Well, since both of them read from cache, they will get the same value. So t2 will read the value before t1 writes to it. Then t1 writes to it and then t2 writes to it. Since they did not use any shared read lock (because the value came from cache and not DB), won't this cause lost update for t1? – shrini1000 Apr 06 '12 at 03:53
  • They will have a shared read lock, on the cache object. Locks don't exist only on the db. Of course this is assuming the cache is configured transactionally. Examples of transactional caches are Infinispan and EhCache. Read this: http://ehcache.org/documentation/apis/jta – Luciano Apr 06 '12 at 04:01
  • Ok, but I'm wondering about what happens if the cache concurrency strategy is read-write, and not transactional. In that case there's no shared lock on cache, so will it cause lost updates for t1? – shrini1000 Apr 06 '12 at 04:16
  • 1
    I'm most familiar with Infinispan, which does not support read-write strategy. On the other hand, it looks like EhCache does. And reading its documentation http://www.ehcache.org/documentation/user-guide/hibernate , on the part about read-write, it says: "Repeatable read isolation is compromised in the case of concurrent writes". So it looks like lost updates can occur. – Luciano Apr 06 '12 at 04:32