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