Hi Simon. > >> DirectMemoryCache is to support all features needed from directmemory to >> support the store, and thus to support extra functions/features or changes >> of behaviour for direct memory needed for ehcache integration which we >> wouldn't necessarily want to put into the core, agreed atm this does make >> this a bit of a pass through layer but i can i can see several items already >> that would want specific to ehcache, atm it has two features it is supplying >> size and capacity in bytes of the cache. >> > > I see, indeed saving sizeInBytes() and capacityInBytes(), it just > wraps CacheService methods, but... what prevents that > DirectMemoryCache uses directly a CacheService instance? I continue > not seeing advantages by this composition, DirectMemoryStore can > comfortably calculate these sizes by invoking the same routines.
Its more about logical ownership, the logic/method of how to retrieve the size in bytes is dependant on the underlying cache in our case DirectMemory, the store should not need to have to have any logic or understanding on how to calculate the size or capacity, it should just be given it. If we can push these two methods to the core cache, then as with below this could be removed until another need arises. > >> On the MemoryManagerServiceWithAllocationPolicyEhcacheImpl this originally >> was to change behaviour of MemoryManagerServiceWithAllocationPolicyImpl to >> throw boe instead of what was the current behaviour of returning null, >> (which actually does cause an npe in the cacheservice implementation which >> probably needs to be fixed) , but anyhow, exception behaviour handling >> allows to wrap into ehcache cache exception nicely. Benoit migrated this >> functionality actually into directmemory core so yes agreed this could be >> removed now. (though i would think about leaving it for now maybe, as with >> like argument for the directmemory cache, if there is features we want >> specific to the ehcache integration, that in furture we wouldnt want in the >> main core, then it is can be placed here). > > I would suggest to keep only lifeblood stuff in order to maintain a > lightweight design, then adding them back in a second time when the > real need comes. agreed this is more agile and as atm we dont have any specifics now for EH i will look to remove if everyone is happy with. > > thanks for your feedbacks!
