I would put it this way.
- as soon as you read data, it is potentially stale (because an update can come along a split second after your read)
- the more frequently your data is updated, the more likely this will be a problem for you
- applications that run on clusters frequently have more traffic (that's why they're on a cluster) and more traffic often coresponds with more updates
- the OR mapper should help the application handle these issues, but cannot do it completely by itself
- The key is really to avoid writing incorrect data.
- A second level cache in certain configurations potentially keeps data that has been read around longer, and as a result, the chances the data is stale go up
- When a second level cache is involved, careful configuration is required to get the proper balance between performance and reducing stale data (hopefully some of the suggestions in the caching document above are helpful)
TopLink Essentials provides some locking strategies to avoid writing stale data and some cache configuration settings that allow you to acheive the balance between performance and avoiding stale data. You can see the configuration options in the posting above.
Oracle TopLink provides some additional options. In addition to our cache coordination feature, we have some additional configuration options:
http://www.oracle.com/technology/products/ias/toplink/doc/10131/main/_html/descun008.htm#sthref2845
http://www.oracle.com/technology/products/ias/toplink/doc/10131/main/_html/cachun002.htm
Some of these features can be configurated with JPA constructs:
http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html#BABHAEGH
There is a strong pull to get all of the above features into open source and into a JPA RI, but I do not have any specific information I can share at the moment.
[Message sent by forum member 'tware' (tware)]
http://forums.java.net/jive/thread.jspa?messageID=237403