openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: [jira] Created: (OPENJPA-556) Data cache infrastructure should take advantage of batching
Date Sat, 05 Apr 2008 00:29:20 GMT
Yeah, it'd definitely be nice to formalize the cache pluggability a
bunch. We haven't done it largely because it's really really hard to
get pluggability APIs right for just one use case, so in the absence
of doing a bunch of plugins, you're unlikely to get it right.

To what extent is the code that you've written something that could be
incorporated into OpenJPA as a more-pluggable infrastructure for
caching? As I mentioned in a different thread, the lack of
license-unencumbered Coherence jars to link against is an issue for
pulling in all the code you've worked on, but it sounds like what
you've done might be well-abstracted anyhow.

The other thing that's always bothered me about OpenJPA's cache
pluggability story is that you've gotta duplicate work for the query
cache and the data cache -- this seems unnecessary.

-Patrick

On Fri, Apr 4, 2008 at 5:25 PM,  <Frederic_Bellier@capgroup.com> wrote:
> alleluia
>
>  I am running Coherence clusters. OpenJPA needs to do the right thing when
>  it comes to interacting with a cache. Otherwise the all performance aspect
>  goes by the window. Which is our reason to use a cache in the first place.
>
>  One small suggestion about OpenJPA and caching in general. I think it would
>  be easier if OpenJPA the O/R Mapping tool and the cache implementation code
>  was separated. Create an new OpenCache open source project and put the code
>  in there.
>  The reason I say this is becuase OpenJPA is quite coupled with its own
>  cache implementation at the moment. I would be quite happy to go in more
>  detail on that one if people are interested. Sepratating the two project
>  might force the dev to create simpler interfaces.
>
>  Seprate the DataCache interface into two - one with the commit method
>  (required for OpenJPA to access the cache) - and create another interface
>  with whatever method you want in there for your cache product.
>  In fact OpenJPA should only need the commit method to a cache facade
>  (interface) to do its works properly.
>  All the other methods in DataCache should not be needed by OpenJPA the O/R
>  mapping tool.
>
>  Just a thought...
>
>
>  Frederic
>
>
>
>
>
>              "Daniel Lee"
>              <tsunfanglee@gmai
>              l.com>                                                     To
>                                        dev@openjpa.apache.org
>                                                                         cc
>              04/04/2008 03:08
>
>              PM                                                    Subject
>                                        Re: [jira] Created: (OPENJPA-556)
>                                        Data cache infrastructure should
>              Please respond to         take advantage of batching
>              dev@openjpa.apach
>                    e.org
>
>
>
>
>
>
>
>
>
>
> It is still a good practice because, for the third party data cache plugins
>  which support special getAll() API to batch the get function may benefit a
>  lot from the implementation, especially in the cluster environment.
>
>  On Fri, Apr 4, 2008 at 2:18 PM, Patrick Linskey <plinskey@gmail.com> wrote:
>
>  > The latest snapshot should have this behavior now.
>  >
>  > >  It won't gain much for OpanJPA "native"
>  > >  data cache since it is delegated to AbstractDataCache.getAll() (ln.
>  > 449)
>  > >  which loops thru the list to get the objects from the cache.  However,
>  > it
>  > >  save the traffic if any.
>  >
>  > Also, the built-in data cache is local-only, with remote invalidations
>  > handled via the RemoteCommitProvider. So the difference between a
>  > series of get() calls vs. batching is negligible anyways.
>  >
>  > -Patrick
>  >
>  > On Fri, Apr 4, 2008 at 1:01 PM, Daniel Lee <tsunfanglee@gmail.com> wrote:
>  > > That's right, that the code here (transformToVersionSafePCDatas) should
>  > call
>  > >  cache.containsAll() or cache.getAll().  That way, it will save a lot
>  > for any
>  > >  data cache that provide getAll().  It won't gain much for OpanJPA
>  > "native"
>  > >  data cache since it is delegated to AbstractDataCache.getAll() (ln.
>  > 449)
>  > >  which loops thru the list to get the objects from the cache.  However,
>  > it
>  > >  save the traffic if any.
>  > >
>  > >  On Thu, Apr 3, 2008 at 11:51 PM, Patrick Linskey (JIRA) <
>  > jira@apache.org>
>  > >  wrote:
>  > >
>  > >
>  > >
>  > >  > Data cache infrastructure should take advantage of batching
>  > >  > -----------------------------------------------------------
>  > >  >
>  > >  >                 Key: OPENJPA-556
>  > >  >                 URL:
>  > https://issues.apache.org/jira/browse/OPENJPA-556
>  > >  >             Project: OpenJPA
>  > >  >          Issue Type: Improvement
>  > >  >            Reporter: Patrick Linskey
>  > >  >
>  > >  >
>  > >  > From the newsgroup:
>  > >  >
>  > >  > "The DataCacheStoreManager.transformToVersionSafePCDatas()  line
>  261.
>  > This
>  > >  > method should call either cache.containsAll() or cache.getAll(). The
>  > >  > current implementation makes one call to the cache for each element
>  > in the
>  > >  > collection."
>  > >  >
>  > >  > --
>  > >  > This message is automatically generated by JIRA.
>  > >  > -
>  > >  > You can reply to this email to add a comment to the issue online.
>  > >  >
>  > >  >
>  > >
>  >
>  >
>  >
>  > --
>  > Patrick Linskey
>  > 202 669 5907
>  >
>
>
>



-- 
Patrick Linskey
202 669 5907

Mime
View raw message