Again, many thanks - one last question ... This is all done in JavaSE - will ehcache help me?
John > -----Ursprüngliche Nachricht----- > Von: Kevin Sutter [mailto:[email protected]] > Gesendet: Montag, 21. Mai 2012 15:11 > An: [email protected] > 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 > <[email protected]>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:[email protected]] > > > Gesendet: Freitag, 18. Mai 2012 20:42 > > > An: [email protected] > > > 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 > > > <[email protected]>wrote: > > > > > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > Von: Boblitz John [mailto:[email protected]] > > > > > Gesendet: Montag, 14. Mai 2012 15:07 > > > > > An: '[email protected]' > > > > > 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 > > > > > >
