db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco Schulze <Ma...@NightLabs.de>
Subject Re: makePersistent detached instance deleted on database
Date Sat, 11 Mar 2006 23:27:04 GMT
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 

The notification mechanism is  push-based.

   |  |  |
   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 

Note, that G can retrieve the objects from E or F.

I hope, I could formulate it understandably ;-)
> Is bidirectional update supported?
> 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 :-)

View raw message