openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <kwsut...@gmail.com>
Subject Re: pro & contra of using Multiple Persistence Units
Date Mon, 21 May 2012 13:36:04 GMT
Yes, the ehcache plugin is designed for JSE...  So, it should work just
fine for you.  Since you are in JSE mode, you may also want to look at the
event notification service that is already provided with OpenJPA -- that
may be sufficient for your needs as well.

Good luck!
Kevin

On Mon, May 21, 2012 at 8:32 AM, Boblitz John <John.Boblitz@bertschi.com>wrote:

> Again, many thanks - one last question ...
>
> This is all done in JavaSE - will ehcache help me?
>
> John
>
> > -----Ursprüngliche Nachricht-----
> > Von: Kevin Sutter [mailto:kwsutter@gmail.com]
> > Gesendet: Montag, 21. Mai 2012 15:11
> > An: users@openjpa.apache.org
> > Betreff: Re: pro & contra of using Multiple Persistence Units
> >
> > OpenJPA's built-in cache does not synch the L2 caches.  You
> > could configure the remote event notification service [1],
> > but that's kind of a cryptic way of getting the cache
> > synchronization to occur.  If you can pre-configure your JMS
> > endpoints or TCPIP ports, then this approach might work.
> > It's been on the ToDo list to improve this built-in
> > capability, but it just hasn't risen in priority.
> >
> > Other alternatives are to use one of the distributed cache
> > plugins for OpenJPA.  If you are a WebSphere customer, you
> > could configure the Dynacache plugin or the WebSphere Extreme
> > Scale plugin.  Outside of WebSphere, ehcache also provides a
> > plugin for use with OpenJPA.  And, if you are ambitious,
> > writing an alternate plugin for your favorite distributed
> > cache is not out of the question.  I'd use the ehcache plugin
> > as an example.
> >
> > Good luck,
> > Kevin
> >
> > [1]
> > http://openjpa.apache.org/builds/latest/docs/docbook/manual.ht
> > ml#ref_guide_event
> >
> > On Mon, May 21, 2012 at 1:37 AM, Boblitz John
> > <John.Boblitz@bertschi.com>wrote:
> >
> > > Hello Kevin,
> > >
> > > Thanks for your response.  Not so sure I can see a need in my
> > > circumstance, but at least it's not a "bad thing to do" :D - maybe
> > > I'll see some areas where this might come in handy ....
> > >
> > > As to the divergent states, I am mostly concerned about the
> > Cache and
> > > ensuring that changes in one pu are "seen" in the other pu if that
> > > entity is cached.
> > >  Perhaps I'm being bull-headed
> > > here, but how can I synch the caches?
> > >
> > > Thanks again & Cheers,
> > >
> > > John
> > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Kevin Sutter [mailto:kwsutter@gmail.com]
> > > > Gesendet: Freitag, 18. Mai 2012 20:42
> > > > An: users@openjpa.apache.org
> > > > Betreff: Re: pro & contra of using Multiple Persistence Units
> > > >
> > > > John, in this case, thanks for the push...  :-)  I had
> > missed your
> > > > first request...
> > > >
> > > > Using multiple persistence units is a fine practice and
> > we recommend
> > > > that approach to many customers.  Even when dealing with the same
> > > > datasource, some applications (or facets of an
> > > > application) just require different configurations for
> > accessing the
> > > > data.  A very common example is with the use of optimistic vs
> > > > pessimistic lock managers.  Some apps may be read-only or
> > > > read-mostly and the default optimistic lock manager is more than
> > > > sufficient.  While, other apps may be heavier on the write
> > > > processing and they may require a pessimistic lock manager.
> > > >
> > > > There are many other cases where the multiple configurations make
> > > > sense.
> > > >
> > > > Of course, many of these configuration items can be
> > controlled from
> > > > within your application as well, but if it's a global
> > configuration
> > > > setting why not just set it in one place and not complicate your
> > > > code?
> > > >
> > > > You mentioned a concern about "divergent states of data"...
> > > > This is really an aspect of your application, not the use of
> > > > multiple persistence units.
> > > > As long as you are using the proper locking mechanism and
> > isolation
> > > > levels when interacting with the database, it doesn't
> > matter if you
> > > > are using one or several PU definitions.
> > > >
> > > > Good luck,
> > > > Kevin
> > > >
> > > > On Fri, May 18, 2012 at 1:28 AM, Boblitz John
> > > > <John.Boblitz@bertschi.com>wrote:
> > > >
> > > > >
> > > > >
> > > > > > -----Ursprüngliche Nachricht-----
> > > > > > Von: Boblitz John [mailto:John.Boblitz@BERTSCHI.com]
> > > > > > Gesendet: Montag, 14. Mai 2012 15:07
> > > > > > An: 'users@openjpa.apache.org'
> > > > > > Betreff: pro & contra of using Multiple Persistence Units
> > > > > >
> > > > > > Good Afternoon,
> > > > > >
> > > > > > I have been looking around the interwebs but can't seem
> > > > to find any
> > > > > > discussions regarding the advantages / disadvantages of using
> > > > > > multiple persistence units in a Java SE environment to
> > > > connect to a
> > > > > > single data source.
> > > > > >
> > > > > > Does anyone know of a good link?
> > > > > >
> > > > > > Also, any info/recomendations from the community would be
> > > > great ...
> > > > > >
> > > > > > A bit of Background:
> > > > > >
> > > > > > I am currently working on an application which splits it's
> > > > > > functionality across several services, mainly based on
> > > > the function
> > > > > > of the data (basic code tables, product data,
> > employee data, etc
> > > > > > ...) and / or an sub-application (Invoicing, etc ...).
> > > > > >
> > > > > > Each of the services will obviously need to access data
> > > > from other
> > > > > > services, and it is currently designed that each service has
> > > > > > it's own Persistence Unit.  IOW, basic code tables
> > are "managed"
> > > > > > in packaged service with it's own persistence
> > > > implementation/unit JAR.
> > > > > >
> > > > > > I am a bit concerned that the various PU's will end up with
> > > > > > divergent states of the data, unless they can somehow be
> > > > synchronized.
> > > > > >
> > > > > > So, what I'm looking for is any information to help me
> > > > decide how to
> > > > > > best configure the persistence unit(s).
> > > > > >
> > > > > >
> > > > > > Thanks & Best Regards
> > > > > >
> > > > > >
> > > > > > 
> > > > > >
> > > > > > John Boblitz
> > > > > >
> > > > > > ----
> > > > > >
> > > > > > Who is General Failure, and why is he reading my hard disk?
> > > > > >
> > > > > >
> > > > >
> > > > > One time push of my previous post, in the hopes that it
> > was simply
> > > > > overseen.  I will not do so again.
> > > > >
> > > > > John
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message