Hi Craig,
after a little conversation with Marco I now understand what the problem
is: calling makePersistent() on a transient instance will transition it
to Persistent-New. Using application identity, that probably won't work
for instances that already exist in the datastore?
Instances with datastore identity will lose their identity inbetween, so
they probably all end up being inserted on makePersistent(), I guess.
That would make for some very redundant replication, I'm afraid ;)
Regards,
Jörg
Marco Schulze schrieb:
Craig L Russell wrote:
Hi Jörg,
Using detachment for replication is an interesting use case, and I'd
like to see more in-depth analysis of the issues that you encounter
once you've done with it.
The use-case for detachment is long-running optimistic transactions,
as you have noted below. We did add makeTransient(Object,
useFetchPlan) as a way to disconnect objects from one datastore that
could be used with another, but I really doubt that we are going to
be able to incorporate into the JDO API all the policy algorithms
needed by a general-purpose replication scheme.
Craig
Hello Craig,
thanks a lot for this hint! I thought the combination of
makeTransient(...) + makePersistent(...) doesn't work, if some of the
objects within the object graph already exist in the destination. Am I
wrong with this thought? Will makePersistent(...) really overwrite
objects that already exist and add objects that are missing in this
case? If so, it's exactly what we need and we're happy. Of course,
it's slightly more work (currently all clients - for both, replication
and normal client usage - call the same EJB methods), but that's only
a minor problem.
Best regards, Marco :-)
