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
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.