Hello Craig,
I assume, Jörg's use case is different from ours, hence I'll describe
ours here:
Craig L Russell wrote:
Hi Jörg,
What I'm looking for first of all is a description of what replication
means to you.
Is it a master/slave configuration where only one of the datastores is
updating instances, and you're pushing out updates?
It's not a usual master-slave configuration where all the data is simply
copied from one master to one (or more) slaves. We have many datastores
(on many servers) involved and some data can come from multiple
datastores. Though, each object has an "owner" datastore. But there
might not be a direct link between the owner of an object and the
receipient of a replication update. There might be other datastores
inbetween.
The notification mechanism is push-based.
Example:
A
|
B--D--F
| | |
C E--G
In this example, an object which has been created by A can be forwarded
through B and D to E. In our scenario, this object would in most of the
cases not be changed by B, D or E, but sometimes they change it (and
this change would then travel back).
Another object which is owned by D would travel to E, through B to A,
and through B to C (and maybe even further depending on the network
configuration).
Note, that G can retrieve the objects from E or F.
I hope, I could formulate it understandably ;-)
Is bidirectional update supported?
Yes.
Does it support application identity as well as datastore identity?
We currently use only application identity.
Is versioning supported?
It would be very helpful if JDO could already do that. A simple
timestamp versioning would be sufficient.
Is there a need for user-written callbacks in case of version failure?
Yes. And it should be possible to attach an object graph which contains
as well older as newer objects than the destination datastore. The older
objects should be silently ignored (or depending on the user choice
cause an exception, but we need silent ignoring) while all the newer
objects should be written (i.e. updated in the destination).
It appears from the description of your proposed feature enhancements
that you're only covering master/slave, application identity, no
versioning, no bidirectional update.
I hope, our scenario is now clearer: We need at least unchecked
replications between datastores (means, the application cares about
preventing the risk of overwriting newer data by older or simply ignores
this problem). If JDO would provide checks (e.g. versioning) and could
handle them in a fault-tolerant way (not throwing an exception, but
simply ignore older data in the attach-process), it would be even
better, but that's not essential.
Craig
Best regards, Marco :-)
