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.bobl...@bertschi.com>wrote: > > > > -----Ursprüngliche Nachricht----- > > Von: Boblitz John [mailto:john.bobl...@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
