That's out it currently is... I've sticked to extending AbstractDataCache On 01 Dec 2009, at 16:54, Kevin Sutter wrote:
> Hi Alex, > In one of your other notes, you had asked about whether to extend > AbstractDataCache or to just start over and implement the DataCache > interface. Unless there is some processing in the AbstractDataCache that is > totally foreign to EHCache, I would suggest extending this implementation. > One thing is that we include our common cache processing (ie, stats > gathering, logging, etc) in the AbstractDataCache. If you don't extend this > implementation, then you won't be participating in this common processing. > Granted, this is limited at the moment, but we have plans to improve on this. > Especially in the area of statistics and monitoring. > > Thanks, > Kevin > > On Tue, Dec 1, 2009 at 9:23 AM, Alex Snaps <[email protected]> wrote: > Kevin, > Thanks for getting back to me on this... I'll look into that CacheMap > DataCache impl. The current EhCacheDataCache seem to not be consistent there > imo. > I'm currently testing my latest fixes with the latest 2.0 Milestone. > I've have the both behavior supported for eviction of entries of the class > including subclasses or not... > I'll probably open Jira's for the rest and see how these get scheduled. > Thanks again, > Alex > > On 01 Dec 2009, at 15:52, Kevin Sutter wrote: > > > Hi Alex, > > The DataCache.writeLock() and .writeUnlock() methods are used to own the > > write lock for the cache. So, your initial thoughts are accurate. If you > > look at the implementation for the embedded cache implementation, you'll > > see where our implementation for CacheMap uses the j.u.c.ReentrantLock > > mechanism for the read and write locks on the cache. Fairly simple, but it > > does the job for our embedded cache implementation. > > > > Your example below of the BrokerImpl.evict processing is eye-opening > > though. It looks like we're relying on the locking mechanism for the > > Broker to protect the cache. Prior to JPA 2.0, this is probably okay since > > the only direct access to the cache was through our own interfaces and > > implementations. But, with the introduction of the public Cache interfaces > > in JPA 2.0, we probably need to ensure that the read/write locks on the > > cache are properly utilized. I'm going to copy Mike on this note for his > > awareness. If this turns out to be a real concern, then we should open a > > JIRA to get this resolved. > > > > Thanks, > > Kevin > > > > On Mon, Nov 23, 2009 at 6:35 AM, Alex Snaps <[email protected]> wrote: > > Hi all, > > I'm currently working on fixing an issue with the EhCache OpenJPA > > cache provider. > > Doing so I ran across the DataCache.writeLock() and writeUnlock() > > methods, which puzzled me a bit. From the naming, I'd like to think > > that owning the write lock, I'll be the only thread mutating the > > cache, yet current implementations I've seen seem to prove me wrong > > (in internal usages e.g. > > org.apache.openjpa.kernel.BrokerImpl.evict(Object, OpCallbacks): void > > or API usages, but the latter could be more of wrong usages as well). > > Anyways, as I haven't found any docs, can someone enlighten me on the > > usage of these methods or point me to some literature ? > > Thanks, > > Alex > > > > -- > > Alex Snaps <[email protected]> > > Software Engineer - Terracotta > > http://twitter.com/alexsnaps > > http://www.linkedin.com/in/alexsnaps > > > >
