openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Boblitz John <John.Bobl...@BERTSCHI.com>
Subject AW: pro & contra of using Multiple Persistence Units
Date Mon, 21 May 2012 13:32:18 GMT
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
View raw message