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 06:37:14 GMT
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