You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Kevin Sutter <kw...@gmail.com> on 2009/12/01 15:52:41 UTC
Re: OpenJPA DataCache.writeLock()
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 <al...@gmail.com> 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 <al...@gmail.com>
> Software Engineer - Terracotta
> http://twitter.com/alexsnaps
> http://www.linkedin.com/in/alexsnaps
>
Re: OpenJPA DataCache.writeLock()
Posted by Alex Snaps <as...@terracottatech.com>.
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 <as...@terracottatech.com> 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 <al...@gmail.com> 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 <al...@gmail.com>
> > Software Engineer - Terracotta
> > http://twitter.com/alexsnaps
> > http://www.linkedin.com/in/alexsnaps
> >
>
>
Re: OpenJPA DataCache.writeLock()
Posted by Kevin Sutter <kw...@gmail.com>.
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 <as...@terracottatech.com>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 <al...@gmail.com>
> 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 <al...@gmail.com>
> > Software Engineer - Terracotta
> > http://twitter.com/alexsnaps
> > http://www.linkedin.com/in/alexsnaps
> >
>
>
Re: OpenJPA DataCache.writeLock()
Posted by Alex Snaps <as...@terracottatech.com>.
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 <al...@gmail.com> 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 <al...@gmail.com>
> Software Engineer - Terracotta
> http://twitter.com/alexsnaps
> http://www.linkedin.com/in/alexsnaps
>