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 >
