[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Coordinating the cache of different PersistenceUnits
|
Hi Gordon,
Thank you very much for your help. I think you've cracked it for me,
what you're saying is:
1) I configure Cache Co-ordination for each ClientSession by registering
a SessionCustomizer which sets up the connection to, for example, a
single JMS topic "jms/singleCacheCoordination" (as described in the
links that you posted and here
http://wiki.eclipse.org/Configuring_a_JMS_Coordinated_Cache_(ELUG) )
2) There's no discrimination between entities updated by different
Persistence Units i.e. each entity has a global identity (which all JPA
entity POJO instances in all L2 caches, regardless of Persistence Unit,
can be identified with) and therefore wherever it's cached in an L2
cache associated with a ClientSession that is subscribed to
"jms/singleCacheCoordination", it will be updated.
Many thanks again for your help,
Steve
Gordon Yorke wrote:
Cache Co-ordination will co-ordinate between different Persistence Units
if all Persistence Units are configured for co-ordination. Information
on configuring Cache-Cordination in EclipseLink can be found here :
http://wiki.eclipse.org/Configuring_a_Coordinated_Cache_(ELUG) In JPA
you will need to use a SessionCustomizer (
http://wiki.eclipse.org/Customizing_the_EclipseLink_Application_(ELUG)#Using_the_Session_Customizer_Class
)and use the JAVA co-ordination configuration.
If you have any other questions feel free to ask.
--Gordon
Steve Sims wrote:
Hello,
I was wondering if somebody could help me with a question about the
relationship between different persistence units, their cache and how
to coordinate them. I'm sorry in advance if this post is a little
basic to post on this list, but I've read through the EJB3-persistence
spec (which correctly leaves implementation details to the JPA
provider) and the eclipselink-a-pedia and wiki which I could follow a
little but don't really know what I'm looking for!
Anyway, I have a core application that represents a number of
different businesses or "Service Providers" to which I'd like to add
specialised Service Provider applications after deployment such as an
application specifically for Restaurants or Taxis etc.
Not knowing too much about database design and architecture, I'm
thinking that the best way to architect it, from a software
perspective is composition; so the core data about a Service Provider
that's common to all providers (such as a phone number, name, address
etc.) would exist in a core Persistence Unit ("corePU") controlled by
a core application with corresponding business logic.
The more specific applications that would be deployed later, say for
example a Restaurant application, would have a Restaurant specific
Persistence Unit ("restPU") and business logic and would store
information about a Restaurant Service Provider that was specialised
such as menus or cost of a meal etc.
So my persistence units would "ideally" look like this:
corePU:
- ServiceProvider Table
- Phone Number
- Name
- Address
restPU:
- Restaurant Table
- ServiceProvider (OneToOne)
- Meal Cost
Unfortunately, because of the ServiceProvider reference, as I need to
run a JPQL query on a Restaurant such as "find all low cost
restaurants near to this address", I need to have the ServiceProvider
objects in the same Persistence Unit as the Restaurant - but they're
also in the the corePU. Just to make it more difficult, I want to run
this in a cluster too!
Therefore, my restaurant persistence units now look like this!
corePU:
- ServiceProvider Table
- Phone Number
- Name
- Address
restPU:
- ServiceProvider Table
- Phone Number
- Name
- Address
- Restaurant Table
- ServiceProvider (OneToOne)
- Meal Cost
So finally (and sorry about this huge post), I have JPA eclipselink L2
cached objects floating around in "corePU" that I update through the
core app's business logic, however I need to see those changes in
"restPU"'s JPQL queries. Therefore, is there any way of getting the L2
cache of "corePU" to synchronise with the L2 cache of "restPU" or am I
going to have to use the Database as my single point and use
EntityManager.flush() in the core app and the QueryHint.REFRESH in
restPU (which is what I'm currently doing but it's presumably going to
kill scalability)?
...or please feel free to tell me if I'm just being silly and abusing
PersistenceUnits?
Many thanks in advance for getting to the end of this post!
Steve
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
