Caching is an important aspect in that it can provide very significant performance improvements versus fetching data from the database. With JPA there is no explicit control over when to use caching, how to invalidate cached data and how this works in a clustered environment.
To be fair this is a non-trivial design issue and it is possibly unfair to ask JPA to specify this. However this does leave open some tough questions for JPA implementations.
To provide a flag to indicate explicitly you want to use a cache is fairly easy. The tough questions revolve around how to invalidate the cache and how clustering effects the cache.
Q: If an external program/Stored Procedure runs how do you notify the framework and how does it know which cached objects should be invalidated?
Q: For a clustered environment how is the cache maintained. More specifically after each commited transaction how much information is sent around the cluster in order to maintain the cache. For example, if every inserted updated or deleted bean is sent across the cluster then this could be a significant amount of data and become prohibative.
Ebean provides a simple mechanisim for explicitly invalidating the cache based on table names. This has the benefit of making it very easy to invalidate the appropriate objects after an external program/Stored Procedure is executed assuming you know the tables involved.
This has the additional benefit of requiring only modified table information to be sent around the cluster rather than the beans or even list of primary key values. This means that the cost of maintaining the cache in a clustered environment is very light.
The downside of this approach is that cache invalidation may be more aggresive invalidating more objects out of the cache than strictly necessary. My opinion is that this downside is more than matched by the simplicity of use and light clustering cost.