Ehcache 3 internals design

[Aurelien Broszniowski]

Hi, 

since Ehcache 3 will be open source, and the people who might want to contribute don't have all the preliminary knowledge about Ehcache internals, could you roughly describe the components hierarchy?

Please correct me when I say incorrect statements, but regarding the tiering discussion, I understand that we want to make Ehcache able to support different tiering mechanisms (heap, offheap, disk, remote storage, per-thread heap...?), and SPI is currently an approach to have a pluggable mechanism.

One part of the API would be to handle the lifecycle of Ehcache (Configuring, starting, stopping)

One part would be to use the cache, and I guess there would be other parts like getting statistics...

But what's behind the API facade? You were mentioning the Ehcache 2 approach  Cache -> Store -> Authority/CachingTier. 

Can you explain what are those components? 

And is this hierarchy what you're thinking of using, or is there another design you're considering?

Aurelien

[Louis Jacomet]

I can provide a quick description of the different elements:

1. Cache: as described in the Javadoc, this is the main user facing class, implementation of Ehcache interface. It offers and performs logical actions.
   All physical actions are delegated to the underlying store. This is also the level at which decorators come into play.
2. Store: This is the level at which physical representation of the cache comes into play. You can have simple memory store directly, more advanced tiering is supported by a specific Store implementation - and this is also where the Terracotta Store fits in for example.
   At this level, a number of Ehcache 2.0 features come into play: copyOnRead/copyOnWrite, transactionality, which are currently implemented as decorators on the physical Store.
3. Authority/CachingTier: These are the underlying implementations for physical storage, when used in a tiered fashion (onheap, offheap, disk). The authority is the larger tier, which will contain all cache entries. The caching tiers are then logically on top of it, containing smaller hot sets of entries.

My understanding is that this design makes for a good separation of concerns currently, so it is a strong contender for the upcoming solution.

Improvements and additions welcome!

Louis

--
You received this message because you are subscribed to the Google Groups "ehcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ehcache-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-dev/09908d49-a841-47db-a6cd-d7daf1789305%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.