openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fernando Padilla <f...@alum.mit.edu>
Subject Re: slices, collocation
Date Tue, 25 Nov 2008 19:51:34 GMT
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. 


Mime
View raw message