Yes, since what is an increment to you (i++) is actually a set to the cache (e.g., set i = blah) where blah has been pre-calculated based on an old value read. So even if you have R_C, even though your tx is re-reading the field at the time of setting, your application is not.
Basically, with R_C, the 2 TXs would be doing this:
i = 10
tx1: set i to 11
tx2: set i to 11 (even though i already is 11)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223594#4223594
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223594
If you are referring to a cache loader, I can't imagine why you would use a cache loader if you are using JBC with Hibernate, since Hibernate already provides persistence.
Using cache loaders with JBC is really for cases where you want cached in-memory state to be persisted (e.g., to disk or a DB) so it survives restarts and it can be evicted from memory when the cache hits certain thresholds.
In the case of a Hibernate 2nd level cache, this is unnecessary since any state in the cache already exists in Hibernate.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223590#4223590
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223590