Below is the precise usecase I'm trying to get to work reliably. And
trying to understand "collocation constraint". So you're saying that I
can always distribute objects into different slices if I call persist on
each one.
The question I have is what would I expect when I try doing
p1.getAddress() ( in another EntityManager, and loading it fresh )?
Person p1 = em2.getReference( p1Id );
Address a1 = p1.getAddress();
logger.debug( "a1: " + a1 );
Pinaki Poddar wrote:
Please note that Slice stores transitive closure of X as it exists at the
point of persist() call. One can exploit that fact to store related
instances in different slices.
For example, assume Person p1 with a reference to Address a1 and that
reference is annotated with CascadeType.PERSIST. The DistributionPolicy is
implemented such that p1 and a1 return different slices S1 and S2:
DistributionPolicy.distribute(p1) = S1
DistributionPolicy.distribute(a1) = S2
Now if we do the following, p1 and a1 will be stored in the same slice S1
Person p1 = new Person();
Address a1 = new Address();
p1.setAddress(a1);
em.persist(p1);
But you can store p1 and a1 in different slices as follows:
Person p1 = new Person();
em.persist(p1);
Address a1 = new Address();
p1.setAddress(a1);
em.persist(p1);
However, it becomes the applications responsibility to reestablish the
linkage between p1 and a1 when they are later realized in a different
persistence context because at the database level p1 stored in slice S1 with
a foreign key for a1 but the Address record with that foreign key actually
sits in slice S2.
