Yeah. I was riding in today and I was thinking about the Replication
feature. I was thinking the same thing about how the Replication slices
and the Distribution slices look a lot a like.. and I was wondering
maybe I didn't see the motivating use-case for the replication feature.
So for me to understand it better.. can you share some use-cases, users
of the Replication feature.. was it a feature needed/used by someone, or
was it just a neat feature to add.. just wondering. I bet it's useful,
but I guess from my app, I don't see a use for it just yet.
Pinaki Poddar wrote:
Hi,
I have finished walking through the whole slices code, and it looks good.
"Proof of the pudding is in eating" :)
I think we need to have a plugin to figure out the slice targets the
queries run against. Currently this is > supported through query "hints",
but I think that is a really bad choice,
The "bad choice" is made to ensure JPA API stability. So far, one of the
strong design constraints in Slice is to place minimal demand to an existing
JPA application and Query hints being a JPA concept, we decided to leverage
the same for narrowing the target slices for a query. But more on this
follows...
when really the ReplicationPolicy is the one that should decide which
classes are replicated and how...
An alternative design possibility is to reinterpret DistributionPolicy
itself and deprecate ReplicationPolicy and @Replicated altogether. The
modified DistributionPolicy method should return an array or list of slice
names -- with the semantics that return value of more than one slices imply
that the input entity is to be replicated.
If we go by that route of modifying DistributionPolicy then it can also
incorporate the Query targets as per your suggestions.
