|
Currently CacheProvider exposes a single method for Hibernate
to obtain a cache adapter (a Cache impl). However, there are numerous
ways in which Hibernate uses the second level cache all of which have slightly
different semantics. As of right now, Hibernate uses the second level
cache for the following: 1) entity data
cache 2) collection
data cache 3) query
results 4) misc
(UpdateTimestampsCache, e.g.) Of these, entity and collection data caches have different
requirements and semantics from, say, storing query results. And the
manner in which update-timestamp info needs to be written into the cache is different
than all the others. I’ve been thinking about splitting up these
abstractions to better align with how we actually use the cache providers in
these different scenarios. Thus, on CacheProvider, instead of just a
single buildCache(…) method we would have separate methods for the
various use cases like buildEntityDataCache(), buildCollectionDataCache(), buildQueryCache(),
buildGeneralCache(). Additionally, we may want to split the Cache
interface into separate interfaces also based on usage; this would only be
intended to allow clearer definition of the capabilities allowed from each usage
scenario. Another nice benefit of this would be to allow “mixed
providers”. Like imagine a clustered data cache along with a local
query cache. Of course, this is a public extension API - so I wanted to put
this out there for discussion. |
_______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
