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 >
