openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <ppod...@apache.org>
Subject Re: slices, collocation
Date Tue, 25 Nov 2008 18:25:03 GMT

Hi,
   I appreciate your thoughtful observations and comments. I hope that your
project will benefit from Slice and design/implementation of Slice, in turn,
will improve from practical use cases and independent views. 

> hmm.  So maybe I was too quick to say that the collocation constraint is
> too inhibiting. 

Constraints are always integral to design. Slice is not a panacea for
distributed data management -- but it does address a specific usage where
data model is amenable to horizontal partition. Such constraints (i.e.
Constrained Tree Schema, if anyone prefers a fancier term) exist *naturally*
in many practical domains on temporal (e.g. PurchaseOrder per Month) or
geographical (e.g. Homes per State) or personal (e.g. Preferences per User)
dimensions. Imposing that constraint upfront, Slice attempts to meets its
goal well with a simple (but not simpler:) implementation that leverages
OpenJPA's excellently extensible architecture (as an adage: Slice required
only one single-line of code change in entire OpenJPA codebase). Such
trade-off between self-imposed constraint and efficiency is core of any
engineering design. 

> Coming from my expectations of what a sharding ORM system would provide
> for me, it definitely is too constraining.  
> I know that with sharding you can never execute a join across databases, 

I am not being able to follow the central argument about why you consider
collocation constraint *too inhibiting'. In fact, the above two statements
seem to contradict each other and justify why Slice has imposed a constraint
on the data model. 

> Just warning people that they have to be careful not to traverse relations
> that are not collocated would be fine.. we're not children after all :) :)

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. 

> But like I said, we're taking a big bet that OpenJPA slices will fit our 
> scale out requirements.  So thank you!  This is an amazing head start, 
> and looks solidly built and coded.  So I'll keep thinking on this, the 
> limitations and possibilities :)  And my complaints are pretty minor in 
> the big picture.

Good luck.


-- 
View this message in context: http://n2.nabble.com/slices%2C-collocation-tp1563065p1577575.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.


Mime
View raw message