You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Erik Bengtson <er...@jpox.org> on 2006/03/08 16:14:01 UTC
makePersistent detached instance deleted on database
Hi,
What happens when we invoke makePersistent on a detached instance that was
deleted by another isolated process? I suspect that we raise an exception
instead of reinserting it for a second time. Is that right?
Maybe this can be clarified in the spec.
Regards,
Re: makePersistent detached instance deleted on database
Posted by Erik Bengtson <er...@jpox.org>.
Craig,
> When you invoke makePersistent on a detached instance, the instance
> must exist in the database. You don't insert it at commit.
It means, we raise an exception.
> This is
> similar to retrieving an instance in one transaction and having a
> parallel transaction delete it.
Unless you use the appropriate isolation levels for this scenario avoiding this
to happen.
Regards,
Quoting Craig L Russell <Cr...@Sun.COM>:
> Hi Erik,
>
> When you invoke makePersistent on a detached instance, the instance
> must exist in the database. You don't insert it at commit. This is
> similar to retrieving an instance in one transaction and having a
> parallel transaction delete it.
>
> Craig
>
> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>
> >
> >
> > Hi,
> >
> > What happens when we invoke makePersistent on a detached instance
> > that was
> > deleted by another isolated process? I suspect that we raise an
> > exception
> > instead of reinserting it for a second time. Is that right?
> >
> > Maybe this can be clarified in the spec.
> >
> > Regards,
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Re: makePersistent detached instance deleted on database
Posted by Marco Schulze <Ma...@NightLabs.de>.
Craig L Russell wrote:
> Hi Jörg,
>
> There are no tests planned for this behavior.
>
> The issue is that it violates the contract of detachment. Detachment
> is intended to provide a "long-running optimistic transaction" in
> which conflicts are detected in a subsequent transaction.
>
> If an instance is detached and then the underlying datastore instance
> is deleted, this is a consistency violation that should be detected
> by the transaction semantics. For example, in an order system, if a
> customer is in a long-running transaction with "groovy beads" in the
> shopping cart, and the administrators decide that "groovy beads" are
> no longer to be sold, you want the order that contains "groovy beads"
> to be rejected when the shopping cart arrives at checkout. You don't
> want that order to reinsert "groovy beads" into the database.
>
> Craig
Hello Craig,
I agree that there are use cases where this kind of datastore-protection
makes sense. But unfortunately this behaviour prevents working with more
than one datastore (or at least makes it VERY complicated). Thus, it's
IMHO a question of weighing which feature is more important.
For us it's essential to work with many datastores and to easily copy
complex object graphs between them. Your use case actually exists in our
system, too. But the object "groovy beads" must not be deleted from the
datastore anymore after it has been "published" once, because the object
already has an important history at that time (e.g. the fact who has
published it when and who has decided when to take it off the
catalogue). Though this is only application specific and my personal
background, I still think that the case you described is more seldom
than data replication and it's easier to work-around.
There would be another possibility: Give each datastore a unique ID
(autogenerate it during creation/initialization of the datastore) and
have the consistency-protection only active when you try to persist an
object graph that was detached from exactly the same datastore.
Best regards, Marco :-)
--
______________________________________________
Initiative baden-württembergischer Unternehmen
gegen Patentierbarkeit von Software
*** http://bw-gegen-softwarepatente.de ***
______________________________________________
Marco Schulze NightLabs GmbH
Rehlingstr. 6d
79100 Freiburg
Germany
eMail: Marco@NightLabs.de
Fon: +49-761-2 111 793
Mobile: +49-172-212 63 80
Fax: +49-761-2 111 798
WWW: http://www.NightLabs.de
Geschäftsführung:
Marco Schulze <Ma...@NightLabs.de>
Niklas Schiffler <Ni...@NightLabs.de>
Eintragung:
Amtsgericht Freiburg, HRB 6186
______________________________________________
Re: makePersistent detached instance deleted on database
Posted by Jörg von Frantzius <jo...@artnology.com>.
Matthew T. Adams schrieb:
> Don't forget that once JPOX starts throwing exceptions during this behavior,
> the exception should contain exceptions for each of the violating detached
> objects (the ones that are to be inserted in the new datastore instead of
> merged). You should be able to handle this in a catch clause, making them
> transient, then persisting the transient instances.
This won't work with datastore identity, as the ids will be lost upon
makeTransient(), and one cannot rely on the second datastore assigning
the same datastore identity to the new instance as did the original
datastore. That's because of different states and behaviours of
sequences in different datastores (potentially from different vendors).
> That way, you can
> continue to merge detached objects across datastores, and still insert new
> ones in a portable way. There would be some issues, however, with regard to
> object references, but I'd expect that you could handle them during
> exception handling.
>
Please see below...
> It's also not the most efficient design, however, as you're almost expecting
> a rollback for the violating detached objects:
>
> public void replicateGraph(Object root, boolean retry) {
>
> try {
> pm.makePersistent(root); // pm is for destination datastore
> return; // happy path
> }
> catch (JDOUserException x) { // I'm not sure of the exact exception type
> here
> if (!retry) {
> throw x;
> }
> // else
> // for each nested exception in x
> // get the deleted detached object
> // make it transient
>
We cannot makeTransient() on a detached instance, Table 2 specifies an
error for that.
> // replace references in the root graph with the newly transient
> objects (might be hard)
>
We could try to find the original instances in the first PM for the
failed detached instances, and making those original instances
transient. After calling makePersistent() for them, the makePersistent()
for the detached graph shouldn't fail anymore.
> // end for
>
> // now recurse (only once)
> replicate(root, false);
> }
> }
>
> Just a thought...
>
Thanks for that thought!
> --matthew
>
>
>> -----Original Message-----
>> From: Jörg von Frantzius [mailto:joerg.von.frantzius@artnology.com]
>> Sent: Thursday, March 09, 2006 10:33 AM
>> To: jdo-dev@db.apache.org
>> Subject: Re: makePersistent detached instance deleted on database
>>
>>
>> Hi Craig,
>>
>> thanks for pointing me to the new makeTransient(Object, useFetchPlan)
>> method, that totally has escaped me. It's support for MaxFetchDepth,
>> DETACH_LOAD_FIELDS, and DETACH_UNLOAD_FIELDS should suffice for
>> replication. Do I understand it right that those parameters
>> are not only
>> applied when loading the "pc or
>> pcs parameter instance(s)", but also for loading reachable instances
>> according to the fetch plan?
>>
>> I'm afraid that JPOX currently supports this only on detaching, though.
>>
>> Detachment for replication is already used in production with an older
>> JPOX version, that still has attachCopy() and insertion of new
>> instances, by the way.
>>
>> Regards,
>> Jörg
>>
>> Craig L Russell schrieb:
>>
>>> 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
>>>
>>> On Mar 9, 2006, at 9:48 AM, Jörg von Frantzius wrote:
>>>
>>>
>>>> Craig L Russell schrieb:
>>>>
>>>>> Hi Jörg,
>>>>>
>>>>> There are no tests planned for this behavior.
>>>>>
>>>> That's good ;-)
>>>>
>>>>> The issue is that it violates the contract of detachment.
>>>>>
>> Detachment
>>
>>>>> is intended to provide a "long-running optimistic transaction" in
>>>>> which conflicts are detected in a subsequent transaction.
>>>>>
>>>> I'd find it a little sad if a great feature like easy
>>>>
>> replication was
>>
>>>> sacrificed in favor of that. Unless replication should be reserved
>>>> for JPOX (using a vendor extension), then maybe a future version of
>>>> the spec could have something along the lines of the solution
>>>> described by Marco in
>>>>
>> http://www.jpox.org/servlet/jira/browse/CORE-2741
>>
>>>> That would be great.
>>>>
>>>> Just for completeness, and maybe it's just me, but the only
>>>>
>> sentence
>>
>>>> about detaching in general that I could find is
>>>> "These methods provide a way for an application to identify
>>>> persistent instances, obtain
>>>> copies of these persistent instances, modify the detached instances
>>>> either in the same JVM
>>>> or in a different JVM, apply the changes to the same or different
>>>> PersistenceManager,
>>>> and commit the changes."
>>>>
>>>> It's not really talking about an equivalent to long-running
>>>> optimistic transactions, I find.
>>>>
>>>>> If an instance is detached and then the underlying datastore
>>>>> instance is deleted, this is a consistency violation that
>>>>>
>> should be
>>
>>>>> detected by the transaction semantics. For example, in an order
>>>>> system, if a customer is in a long-running transaction
>>>>>
>> with "groovy
>>
>>>>> beads" in the shopping cart, and the administrators decide that
>>>>> "groovy beads" are no longer to be sold, you want the order that
>>>>> contains "groovy beads" to be rejected when the shopping cart
>>>>> arrives at checkout. You don't want that order to reinsert "groovy
>>>>> beads" into the database.
>>>>>
>>>> I agree that this surely must be catered for.
>>>>
>>>>> Craig
>>>>>
>>>>> On Mar 9, 2006, at 8:40 AM, Jörg von Frantzius wrote:
>>>>>
>>>>>
>>>>>> Hi Craig,
>>>>>>
>>>>>> I was already afraid that "create a persistent instance"
>>>>>>
>> might only
>>
>>>>>> apply to the PM cache, not the datastore (but only after second
>>>>>> read). However, would you say that JPOX is not JDO2
>>>>>>
>> compliant if it
>>
>>>>>> created missing instances in the datastore anyway? Will
>>>>>>
>> there be a
>>
>>>>>> test in the TCK2 that expects an exception to be thrown if a
>>>>>> detached instances does not exist in the datastore?
>>>>>>
>>>>>> And, most of all, what sense would it make to forbid the creation
>>>>>> of missing detached instances in the datastore? There is lots of
>>>>>> application for that behaviour, and at least I don't know of any
>>>>>> problem with it.
>>>>>>
>>>>>> Regards,
>>>>>> Jörg
>>>>>>
>>>>>> Craig L Russell schrieb:
>>>>>>
>>>>>>> Hi Jörg,
>>>>>>>
>>>>>>> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Craig L Russell schrieb:
>>>>>>>>
>>>>>>>>>> Also I find it confusing that the method most
>>>>>>>>>>
>> prominently used
>>
>>>>>>>>>> for inserting new objects shouldn't do so for
>>>>>>>>>>
>> detached instances.
>>
>>>>>>>>> There is a bunch of history that you should look at, most of
>>>>>>>>> which is in the jdo-dev archives. Bottom line, we used
>>>>>>>>>
>> to have a
>>
>>>>>>>>> different API, attachCopy, but we looked at what it had to do
>>>>>>>>> for transient and detached instances and decided that
>>>>>>>>>
>> it wasn't
>>
>>>>>>>>> worth making a different API for attaching detached instances.
>>>>>>>>>
>>>>>>>> That particular behaviour of attachCopy() wasn't really
>>>>>>>> specified, but it was pleasant JPOX-specific behaviour, if I
>>>>>>>> remember correctly. I saw the discussion and I didn't see where
>>>>>>>> inserting the instances would be forbidden by the spec,
>>>>>>>>
>> and still
>>
>>>>>>>> I don't see where it says that, especially in the light of
>>>>>>>> 12.6.7. Please excuse my ignorance, where does it say that?
>>>>>>>>
>>>>>>> <spec>
>>>>>>> These methods make transient instances persistent and apply
>>>>>>> detached instance changes
>>>>>>> to the cache.
>>>>>>> ...
>>>>>>> For a detached instance, they locate or create a persistent
>>>>>>> instance with the same JDO identity as the detached
>>>>>>>
>> instance, and
>>
>>>>>>> merge the persistent
>>>>>>> state of the detached instance into the persistent
>>>>>>>
>> instance. Only
>>
>>>>>>> the state of persistent fields
>>>>>>> is merged.
>>>>>>> </spec>
>>>>>>>
>>>>>>> This means that if there is already a persistent instance in the
>>>>>>> cache with the same object id as the detached instance, the
>>>>>>> detached state will be merged. If there is not a persistent
>>>>>>> instance in the cache, a cache instance is created and the
>>>>>>> detached state is merged with the persistent instance.
>>>>>>>
>>>>>>> But there is no creation aspect of makePersistent on a detached
>>>>>>> instance.
>>>>>>>
>>>>>>> Craig
>>>>>>>
>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Craig
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Craig
>>>>>>>>>>>
>>>>>>>>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> What happens when we invoke makePersistent on a detached
>>>>>>>>>>>> instance that was
>>>>>>>>>>>> deleted by another isolated process? I suspect that
>>>>>>>>>>>>
>> we raise
>>
>>>>>>>>>>>> an exception
>>>>>>>>>>>> instead of reinserting it for a second time. Is that right?
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe this can be clarified in the spec.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>> Craig Russell
>>>>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Craig Russell
>>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>
>>>>>>>>>
>>>>>>> Craig Russell
>>>>>>> Architect, Sun Java Enterprise System
>>>>>>> http://java.sun.com/products/jdo
>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>
>>>>>>>
>>>>> Craig Russell
>>>>> Architect, Sun Java Enterprise System
>>>>>
>> http://java.sun.com/products/jdo
>>
>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System
>>>
>> http://java.sun.com/products/jdo
>>
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>
>
>
>
>
>
RE: makePersistent detached instance deleted on database
Posted by "Matthew T. Adams" <ma...@xcalia.com>.
Don't forget that once JPOX starts throwing exceptions during this behavior,
the exception should contain exceptions for each of the violating detached
objects (the ones that are to be inserted in the new datastore instead of
merged). You should be able to handle this in a catch clause, making them
transient, then persisting the transient instances. That way, you can
continue to merge detached objects across datastores, and still insert new
ones in a portable way. There would be some issues, however, with regard to
object references, but I'd expect that you could handle them during
exception handling.
It's also not the most efficient design, however, as you're almost expecting
a rollback for the violating detached objects:
public void replicateGraph(Object root, boolean retry) {
try {
pm.makePersistent(root); // pm is for destination datastore
return; // happy path
}
catch (JDOUserException x) { // I'm not sure of the exact exception type
here
if (!retry) {
throw x;
}
// else
// for each nested exception in x
// get the deleted detached object
// make it transient
// replace references in the root graph with the newly transient
objects (might be hard)
// end for
// now recurse (only once)
replicate(root, false);
}
}
Just a thought...
--matthew
>-----Original Message-----
>From: Jörg von Frantzius [mailto:joerg.von.frantzius@artnology.com]
>Sent: Thursday, March 09, 2006 10:33 AM
>To: jdo-dev@db.apache.org
>Subject: Re: makePersistent detached instance deleted on database
>
>
>Hi Craig,
>
>thanks for pointing me to the new makeTransient(Object, useFetchPlan)
>method, that totally has escaped me. It's support for MaxFetchDepth,
>DETACH_LOAD_FIELDS, and DETACH_UNLOAD_FIELDS should suffice for
>replication. Do I understand it right that those parameters
>are not only
>applied when loading the "pc or
>pcs parameter instance(s)", but also for loading reachable instances
>according to the fetch plan?
>
>I'm afraid that JPOX currently supports this only on detaching, though.
>
>Detachment for replication is already used in production with an older
>JPOX version, that still has attachCopy() and insertion of new
>instances, by the way.
>
>Regards,
>Jörg
>
>Craig L Russell schrieb:
>> 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
>>
>> On Mar 9, 2006, at 9:48 AM, Jörg von Frantzius wrote:
>>
>>> Craig L Russell schrieb:
>>>> Hi Jörg,
>>>>
>>>> There are no tests planned for this behavior.
>>> That's good ;-)
>>>>
>>>> The issue is that it violates the contract of detachment.
>Detachment
>>>> is intended to provide a "long-running optimistic transaction" in
>>>> which conflicts are detected in a subsequent transaction.
>>> I'd find it a little sad if a great feature like easy
>replication was
>>> sacrificed in favor of that. Unless replication should be reserved
>>> for JPOX (using a vendor extension), then maybe a future version of
>>> the spec could have something along the lines of the solution
>>> described by Marco in
>http://www.jpox.org/servlet/jira/browse/CORE-2741
>>>
>>> That would be great.
>>>
>>> Just for completeness, and maybe it's just me, but the only
>sentence
>>> about detaching in general that I could find is
>>> "These methods provide a way for an application to identify
>>> persistent instances, obtain
>>> copies of these persistent instances, modify the detached instances
>>> either in the same JVM
>>> or in a different JVM, apply the changes to the same or different
>>> PersistenceManager,
>>> and commit the changes."
>>>
>>> It's not really talking about an equivalent to long-running
>>> optimistic transactions, I find.
>>>> If an instance is detached and then the underlying datastore
>>>> instance is deleted, this is a consistency violation that
>should be
>>>> detected by the transaction semantics. For example, in an order
>>>> system, if a customer is in a long-running transaction
>with "groovy
>>>> beads" in the shopping cart, and the administrators decide that
>>>> "groovy beads" are no longer to be sold, you want the order that
>>>> contains "groovy beads" to be rejected when the shopping cart
>>>> arrives at checkout. You don't want that order to reinsert "groovy
>>>> beads" into the database.
>>> I agree that this surely must be catered for.
>>>>
>>>> Craig
>>>>
>>>> On Mar 9, 2006, at 8:40 AM, Jörg von Frantzius wrote:
>>>>
>>>>> Hi Craig,
>>>>>
>>>>> I was already afraid that "create a persistent instance"
>might only
>>>>> apply to the PM cache, not the datastore (but only after second
>>>>> read). However, would you say that JPOX is not JDO2
>compliant if it
>>>>> created missing instances in the datastore anyway? Will
>there be a
>>>>> test in the TCK2 that expects an exception to be thrown if a
>>>>> detached instances does not exist in the datastore?
>>>>>
>>>>> And, most of all, what sense would it make to forbid the creation
>>>>> of missing detached instances in the datastore? There is lots of
>>>>> application for that behaviour, and at least I don't know of any
>>>>> problem with it.
>>>>>
>>>>> Regards,
>>>>> Jörg
>>>>>
>>>>> Craig L Russell schrieb:
>>>>>> Hi Jörg,
>>>>>>
>>>>>> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>>>>>>
>>>>>>> Craig L Russell schrieb:
>>>>>>>>> Also I find it confusing that the method most
>prominently used
>>>>>>>>> for inserting new objects shouldn't do so for
>detached instances.
>>>>>>>>
>>>>>>>> There is a bunch of history that you should look at, most of
>>>>>>>> which is in the jdo-dev archives. Bottom line, we used
>to have a
>>>>>>>> different API, attachCopy, but we looked at what it had to do
>>>>>>>> for transient and detached instances and decided that
>it wasn't
>>>>>>>> worth making a different API for attaching detached instances.
>>>>>>> That particular behaviour of attachCopy() wasn't really
>>>>>>> specified, but it was pleasant JPOX-specific behaviour, if I
>>>>>>> remember correctly. I saw the discussion and I didn't see where
>>>>>>> inserting the instances would be forbidden by the spec,
>and still
>>>>>>> I don't see where it says that, especially in the light of
>>>>>>> 12.6.7. Please excuse my ignorance, where does it say that?
>>>>>>
>>>>>> <spec>
>>>>>> These methods make transient instances persistent and apply
>>>>>> detached instance changes
>>>>>> to the cache.
>>>>>> ...
>>>>>> For a detached instance, they locate or create a persistent
>>>>>> instance with the same JDO identity as the detached
>instance, and
>>>>>> merge the persistent
>>>>>> state of the detached instance into the persistent
>instance. Only
>>>>>> the state of persistent fields
>>>>>> is merged.
>>>>>> </spec>
>>>>>>
>>>>>> This means that if there is already a persistent instance in the
>>>>>> cache with the same object id as the detached instance, the
>>>>>> detached state will be merged. If there is not a persistent
>>>>>> instance in the cache, a cache instance is created and the
>>>>>> detached state is merged with the persistent instance.
>>>>>>
>>>>>> But there is no creation aspect of makePersistent on a detached
>>>>>> instance.
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Craig
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Craig
>>>>>>>>>>
>>>>>>>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> What happens when we invoke makePersistent on a detached
>>>>>>>>>>> instance that was
>>>>>>>>>>> deleted by another isolated process? I suspect that
>we raise
>>>>>>>>>>> an exception
>>>>>>>>>>> instead of reinserting it for a second time. Is that right?
>>>>>>>>>>>
>>>>>>>>>>> Maybe this can be clarified in the spec.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Craig Russell
>>>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Craig Russell
>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Craig Russell
>>>>>> Architect, Sun Java Enterprise System
>>>>>> http://java.sun.com/products/jdo
>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>>
>>>>
>>>> Craig Russell
>>>> Architect, Sun Java Enterprise System
>http://java.sun.com/products/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System
>http://java.sun.com/products/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
>
Re: makePersistent detached instance deleted on database
Posted by Jörg von Frantzius <jo...@artnology.com>.
Hi Craig,
thanks for pointing me to the new makeTransient(Object, useFetchPlan)
method, that totally has escaped me. It's support for MaxFetchDepth,
DETACH_LOAD_FIELDS, and DETACH_UNLOAD_FIELDS should suffice for
replication. Do I understand it right that those parameters are not only
applied when loading the "pc or
pcs parameter instance(s)", but also for loading reachable instances
according to the fetch plan?
I'm afraid that JPOX currently supports this only on detaching, though.
Detachment for replication is already used in production with an older
JPOX version, that still has attachCopy() and insertion of new
instances, by the way.
Regards,
Jörg
Craig L Russell schrieb:
> 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
>
> On Mar 9, 2006, at 9:48 AM, Jörg von Frantzius wrote:
>
>> Craig L Russell schrieb:
>>> Hi Jörg,
>>>
>>> There are no tests planned for this behavior.
>> That's good ;-)
>>>
>>> The issue is that it violates the contract of detachment. Detachment
>>> is intended to provide a "long-running optimistic transaction" in
>>> which conflicts are detected in a subsequent transaction.
>> I'd find it a little sad if a great feature like easy replication was
>> sacrificed in favor of that. Unless replication should be reserved
>> for JPOX (using a vendor extension), then maybe a future version of
>> the spec could have something along the lines of the solution
>> described by Marco in http://www.jpox.org/servlet/jira/browse/CORE-2741
>>
>> That would be great.
>>
>> Just for completeness, and maybe it's just me, but the only sentence
>> about detaching in general that I could find is
>> "These methods provide a way for an application to identify
>> persistent instances, obtain
>> copies of these persistent instances, modify the detached instances
>> either in the same JVM
>> or in a different JVM, apply the changes to the same or different
>> PersistenceManager,
>> and commit the changes."
>>
>> It's not really talking about an equivalent to long-running
>> optimistic transactions, I find.
>>> If an instance is detached and then the underlying datastore
>>> instance is deleted, this is a consistency violation that should be
>>> detected by the transaction semantics. For example, in an order
>>> system, if a customer is in a long-running transaction with "groovy
>>> beads" in the shopping cart, and the administrators decide that
>>> "groovy beads" are no longer to be sold, you want the order that
>>> contains "groovy beads" to be rejected when the shopping cart
>>> arrives at checkout. You don't want that order to reinsert "groovy
>>> beads" into the database.
>> I agree that this surely must be catered for.
>>>
>>> Craig
>>>
>>> On Mar 9, 2006, at 8:40 AM, Jörg von Frantzius wrote:
>>>
>>>> Hi Craig,
>>>>
>>>> I was already afraid that "create a persistent instance" might only
>>>> apply to the PM cache, not the datastore (but only after second
>>>> read). However, would you say that JPOX is not JDO2 compliant if it
>>>> created missing instances in the datastore anyway? Will there be a
>>>> test in the TCK2 that expects an exception to be thrown if a
>>>> detached instances does not exist in the datastore?
>>>>
>>>> And, most of all, what sense would it make to forbid the creation
>>>> of missing detached instances in the datastore? There is lots of
>>>> application for that behaviour, and at least I don't know of any
>>>> problem with it.
>>>>
>>>> Regards,
>>>> Jörg
>>>>
>>>> Craig L Russell schrieb:
>>>>> Hi Jörg,
>>>>>
>>>>> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>>>>>
>>>>>> Craig L Russell schrieb:
>>>>>>>> Also I find it confusing that the method most prominently used
>>>>>>>> for inserting new objects shouldn't do so for detached instances.
>>>>>>>
>>>>>>> There is a bunch of history that you should look at, most of
>>>>>>> which is in the jdo-dev archives. Bottom line, we used to have a
>>>>>>> different API, attachCopy, but we looked at what it had to do
>>>>>>> for transient and detached instances and decided that it wasn't
>>>>>>> worth making a different API for attaching detached instances.
>>>>>> That particular behaviour of attachCopy() wasn't really
>>>>>> specified, but it was pleasant JPOX-specific behaviour, if I
>>>>>> remember correctly. I saw the discussion and I didn't see where
>>>>>> inserting the instances would be forbidden by the spec, and still
>>>>>> I don't see where it says that, especially in the light of
>>>>>> 12.6.7. Please excuse my ignorance, where does it say that?
>>>>>
>>>>> <spec>
>>>>> These methods make transient instances persistent and apply
>>>>> detached instance changes
>>>>> to the cache.
>>>>> ...
>>>>> For a detached instance, they locate or create a persistent
>>>>> instance with the same JDO identity as the detached instance, and
>>>>> merge the persistent
>>>>> state of the detached instance into the persistent instance. Only
>>>>> the state of persistent fields
>>>>> is merged.
>>>>> </spec>
>>>>>
>>>>> This means that if there is already a persistent instance in the
>>>>> cache with the same object id as the detached instance, the
>>>>> detached state will be merged. If there is not a persistent
>>>>> instance in the cache, a cache instance is created and the
>>>>> detached state is merged with the persistent instance.
>>>>>
>>>>> But there is no creation aspect of makePersistent on a detached
>>>>> instance.
>>>>>
>>>>> Craig
>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Craig
>>>>>>>
>>>>>>>>>
>>>>>>>>> Craig
>>>>>>>>>
>>>>>>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> What happens when we invoke makePersistent on a detached
>>>>>>>>>> instance that was
>>>>>>>>>> deleted by another isolated process? I suspect that we raise
>>>>>>>>>> an exception
>>>>>>>>>> instead of reinserting it for a second time. Is that right?
>>>>>>>>>>
>>>>>>>>>> Maybe this can be clarified in the spec.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Craig Russell
>>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Craig Russell
>>>>>>> Architect, Sun Java Enterprise System
>>>>>>> http://java.sun.com/products/jdo
>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>
>>>>>>
>>>>>
>>>>> Craig Russell
>>>>> Architect, Sun Java Enterprise System
>>>>> http://java.sun.com/products/jdo
>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: makePersistent detached instance deleted on database
Posted by Jörg von Frantzius <jo...@artnology.com>.
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 :-)
>
>
Re: makePersistent detached instance deleted on database
Posted by Marco Schulze <Ma...@NightLabs.de>.
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 :-)
Re: makePersistent detached instance deleted on database
Posted by Jörg von Frantzius <jo...@artnology.com>.
I just realize that the proposed new method
PersistenceManager.makePersistent(Object o, boolean insertNew) is rather
confusing, since the parameter only makes sense for detached instances.
I'm afraid this calls out for good old attachCopy(), only with an
additional parameter:
Object attachCopy(Object detached, boolean insertNonExisting);
Object[] attachCopyAll(Object[] detached, boolean insertNonExisting);
Collection attachCopyAll(Collection detached, boolean insertNonExisting);
The behaviour of makePersistent() for transient instances would not be
affected, but it should throw exception when invoked with detached
instances. Consequently, there's no need for any return values anymore,
as the copy-semantics would be removed. That would make it look like in
JDO 1.0.1 again:
void makePersistent (Object pc);
void makePersistentAll (Object[] pcs);
void makePersistentAll (Collection pcs);
To sum up the advantages of these changes:
* good support for replication,
* copy semantics entirely removed from makePersistent,
* copy semantics flagged in the method name attachCopy()
* clean separation of concerns
The currently mixed copy/non-copy semantics of makePersistent(),
depending on the state of the input parameter, aren't exactly beautiful
anyway, IMHO.
Regards,
Jörg
Jörg von Frantzius schrieb:
> Hi Craig,
>
> sorry I didn't understand what you wanted to see here exactly. Maybe
> something like this:
>
> Replication does work perfectly with detaching using an attachCopy()
> that inserts new instances, and it does so in a productive environment
> using an older JPOX version, however compliant with the spec that was.
>
> With the current specification, there is one thinkable approach that
> might work (as pointed out by Matthew), and it has two drawbacks.
> Here's what it could look like:
>
> Object detachedGraph = pm1.detachCopy(root);
> try {
> pm2.makePersistent(detachedGraph);
> } catch (whatever Exception it is exactly) {
> Collection failedInstances = ... // failed are contained in exception
> // find out the original instances of the failed detached instances
> Collection originalFailedInstances;
> for (Object failed: failedInstances) {
> Object originalFailed = pm1.getObjectById(JDOHelper.getObjectId(failed));
> originalFailedInstances.add(originalFailed);
> }
> pm1.makeTransientAll(originalFailedInstances);
> pm2.makePersistentAll(originalFailedInstances);
> // now that the new objects are made persistent, this should succeed:
> pm2.makePersistent(detachedGraph);
> }
>
> The drawbacks are:
>
> 1. it *won't work for datastore identity*, as the identities of the
> instances new to the second PM/datastore are lost upon
> makeTransient(), and there is no reliable way to assure that
> they will be assigned the same identities upon makePersistent()
> on the second PM,
> 2. it certainly is *not very effective*.
>
> The remedy could be the approach proposed by Marco: to have an
> additional method
>
> PersistenceManager.makePersistent(Object o, boolean insertNew)
>
> and to have PersistenceManager.makePersistent(Object) default to
> PersistenceManager.makePersistent(o, false).
>
> Regards,
> Jörg
>
> Craig L Russell schrieb:
>> Hi Jörg,
>>
>> As I said earlier, I'd like to see the details of using this feature
>> for replication. What cases are covered, what cases are still
>> problematic, what modifications to the specification are needed in
>> order to accomplish the task?
>>
>> Craig
>>
>> On Mar 10, 2006, at 3:14 AM, Jörg von Frantzius wrote:
>>
>>> Hi Craig,
>>>
>>> replication really is lost in a specification gap: makePersistent()
>>> on transient instances won't update existing data, and on detached
>>> instances it won't insert new. For replication, you need both
>>> behaviours at the same time.
>>>
>>> That's really misfortunate for such a nice feature! Even more so as
>>> it is not just theory, but it proves to be working in production
>>> with JPOX' old implementation of attachCopy().
>>>
>>> Regards,
>>> Jörg
>>>
>>> Craig L Russell schrieb:
>>>> 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
>>>>
>>>> On Mar 9, 2006, at 9:48 AM, Jörg von Frantzius wrote:
>>>>
>>>>> Craig L Russell schrieb:
>>>>>> Hi Jörg,
>>>>>>
>>>>>> There are no tests planned for this behavior.
>>>>> That's good ;-)
>>>>>>
>>>>>> The issue is that it violates the contract of detachment.
>>>>>> Detachment is intended to provide a "long-running optimistic
>>>>>> transaction" in which conflicts are detected in a subsequent
>>>>>> transaction.
>>>>> I'd find it a little sad if a great feature like easy replication
>>>>> was sacrificed in favor of that. Unless replication should be
>>>>> reserved for JPOX (using a vendor extension), then maybe a future
>>>>> version of the spec could have something along the lines of the
>>>>> solution described by Marco in
>>>>> http://www.jpox.org/servlet/jira/browse/CORE-2741
>>>>>
>>>>> That would be great.
>>>>>
>>>>> Just for completeness, and maybe it's just me, but the only
>>>>> sentence about detaching in general that I could find is
>>>>> "These methods provide a way for an application to identify
>>>>> persistent instances, obtain
>>>>> copies of these persistent instances, modify the detached
>>>>> instances either in the same JVM
>>>>> or in a different JVM, apply the changes to the same or different
>>>>> PersistenceManager,
>>>>> and commit the changes."
>>>>>
>>>>> It's not really talking about an equivalent to long-running
>>>>> optimistic transactions, I find.
>>>>>> If an instance is detached and then the underlying datastore
>>>>>> instance is deleted, this is a consistency violation that should
>>>>>> be detected by the transaction semantics. For example, in an
>>>>>> order system, if a customer is in a long-running transaction with
>>>>>> "groovy beads" in the shopping cart, and the administrators
>>>>>> decide that "groovy beads" are no longer to be sold, you want the
>>>>>> order that contains "groovy beads" to be rejected when the
>>>>>> shopping cart arrives at checkout. You don't want that order to
>>>>>> reinsert "groovy beads" into the database.
>>>>> I agree that this surely must be catered for.
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>> On Mar 9, 2006, at 8:40 AM, Jörg von Frantzius wrote:
>>>>>>
>>>>>>> Hi Craig,
>>>>>>>
>>>>>>> I was already afraid that "create a persistent instance" might
>>>>>>> only apply to the PM cache, not the datastore (but only after
>>>>>>> second read). However, would you say that JPOX is not JDO2
>>>>>>> compliant if it created missing instances in the datastore
>>>>>>> anyway? Will there be a test in the TCK2 that expects an
>>>>>>> exception to be thrown if a detached instances does not exist in
>>>>>>> the datastore?
>>>>>>>
>>>>>>> And, most of all, what sense would it make to forbid the
>>>>>>> creation of missing detached instances in the datastore? There
>>>>>>> is lots of application for that behaviour, and at least I don't
>>>>>>> know of any problem with it.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jörg
>>>>>>>
>>>>>>> Craig L Russell schrieb:
>>>>>>>> Hi Jörg,
>>>>>>>>
>>>>>>>> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>>>>>>>>
>>>>>>>>> Craig L Russell schrieb:
>>>>>>>>>>> Also I find it confusing that the method most prominently
>>>>>>>>>>> used for inserting new objects shouldn't do so for detached
>>>>>>>>>>> instances.
>>>>>>>>>>
>>>>>>>>>> There is a bunch of history that you should look at, most of
>>>>>>>>>> which is in the jdo-dev archives. Bottom line, we used to
>>>>>>>>>> have a different API, attachCopy, but we looked at what it
>>>>>>>>>> had to do for transient and detached instances and decided
>>>>>>>>>> that it wasn't worth making a different API for attaching
>>>>>>>>>> detached instances.
>>>>>>>>> That particular behaviour of attachCopy() wasn't really
>>>>>>>>> specified, but it was pleasant JPOX-specific behaviour, if I
>>>>>>>>> remember correctly. I saw the discussion and I didn't see
>>>>>>>>> where inserting the instances would be forbidden by the spec,
>>>>>>>>> and still I don't see where it says that, especially in the
>>>>>>>>> light of 12.6.7. Please excuse my ignorance, where does it say
>>>>>>>>> that?
>>>>>>>>
>>>>>>>> <spec>
>>>>>>>> These methods make transient instances persistent and apply
>>>>>>>> detached instance changes
>>>>>>>> to the cache.
>>>>>>>> ...
>>>>>>>> For a detached instance, they locate or create a persistent
>>>>>>>> instance with the same JDO identity as the detached instance,
>>>>>>>> and merge the persistent
>>>>>>>> state of the detached instance into the persistent instance.
>>>>>>>> Only the state of persistent fields
>>>>>>>> is merged.
>>>>>>>> </spec>
>>>>>>>>
>>>>>>>> This means that if there is already a persistent instance in
>>>>>>>> the cache with the same object id as the detached instance, the
>>>>>>>> detached state will be merged. If there is not a persistent
>>>>>>>> instance in the cache, a cache instance is created and the
>>>>>>>> detached state is merged with the persistent instance.
>>>>>>>>
>>>>>>>> But there is no creation aspect of makePersistent on a detached
>>>>>>>> instance.
>>>>>>>>
>>>>>>>> Craig
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Craig
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Craig
>>>>>>>>>>>>
>>>>>>>>>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> What happens when we invoke makePersistent on a detached
>>>>>>>>>>>>> instance that was
>>>>>>>>>>>>> deleted by another isolated process? I suspect that we
>>>>>>>>>>>>> raise an exception
>>>>>>>>>>>>> instead of reinserting it for a second time. Is that right?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe this can be clarified in the spec.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Craig Russell
>>>>>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Craig Russell
>>>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Craig Russell
>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Craig Russell
>>>>>> Architect, Sun Java Enterprise System
>>>>>> http://java.sun.com/products/jdo
>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>>
>>>>
>>>> Craig Russell
>>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Re: makePersistent detached instance deleted on database
Posted by Marco Schulze <Ma...@NightLabs.de>.
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 :-)
Re: makePersistent detached instance deleted on database
Posted by Jörg von Frantzius <jo...@artnology.com>.
Hello Craig,
Craig L Russell schrieb:
> 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?
>
> Is bidirectional update supported?
>
> Does it support application identity as well as datastore identity?
>
> Is versioning supported?
We're using timestamps issued by the master datastore to find changes.
Or do you mean optimistic versioning here?
> Is there a need for user-written callbacks in case of version failure?
>
> It appears from the description of your proposed feature enhancements
> that you're only covering master/slave, application identity, no
> versioning, no bidirectional update.
That's exactly the kind of replication we're doing here!
Fortunately bidirectional replication wasn't a requirement, as one would
have to either think of some kind of distributed locking scheme, or
conflict resolution. I'm not sure whether that should make any
difference for the JDO API, unless we'd want to provide support for
conflict resolution e.g. by reflecting upon individual fields that have
conflicting changes. Are you thinking of support for one or both of the
two approaches in the spec?
Regards,
Jörg
> Craig
>
> On Mar 10, 2006, at 9:22 AM, Jörg von Frantzius wrote:
>
>> Hi Craig,
>>
>> sorry I didn't understand what you wanted to see here exactly. Maybe
>> something like this:
>>
>> Replication does work perfectly with detaching using an attachCopy()
>> that inserts new instances, and it does so in a productive
>> environment using an older JPOX version, however compliant with the
>> spec that was.
>>
>> With the current specification, there is one thinkable approach that
>> might work (as pointed out by Matthew), and it has two drawbacks.
>> Here's what it could look like:
>>
>> Object detachedGraph = pm1.detachCopy(root);
>> try {
>> pm2.makePersistent(detachedGraph);
>> } catch (whatever Exception it is exactly) {
>> Collection failedInstances = ... // failed are contained in exception
>> // find out the original instances of the failed detached instances
>> Collection originalFailedInstances;
>> for (Object failed: failedInstances) {
>> Object originalFailed = pm1.getObjectById(JDOHelper.getObjectId(failed));
>> originalFailedInstances.add(originalFailed);
>> }
>> pm1.makeTransientAll(originalFailedInstances);
>> pm2.makePersistentAll(originalFailedInstances);
>> // now that the new objects are made persistent, this should succeed:
>> pm2.makePersistent(detachedGraph);
>> }
>>
>> The drawbacks are:
>>
>> 1. it *won't work for datastore identity*, as the identities of
>> the instances new to the second PM/datastore are lost upon
>> makeTransient(), and there is no reliable way to assure that
>> they will be assigned the same identities upon makePersistent()
>> on the second PM,
>> 2. it certainly is *not very effective*.
>>
>> The remedy could be the approach proposed by Marco: to have an
>> additional method
>>
>> PersistenceManager.makePersistent(Object o, boolean insertNew)
>>
>> and to have PersistenceManager.makePersistent(Object) default to
>> PersistenceManager.makePersistent(o, false).
>>
>> Regards,
>> Jörg
>>
>> Craig L Russell schrieb:
>>> Hi Jörg,
>>>
>>> As I said earlier, I'd like to see the details of using this feature
>>> for replication. What cases are covered, what cases are still
>>> problematic, what modifications to the specification are needed in
>>> order to accomplish the task?
>>>
>>> Craig
>>>
>>> On Mar 10, 2006, at 3:14 AM, Jörg von Frantzius wrote:
>>>
>>>> Hi Craig,
>>>>
>>>> replication really is lost in a specification gap: makePersistent()
>>>> on transient instances won't update existing data, and on detached
>>>> instances it won't insert new. For replication, you need both
>>>> behaviours at the same time.
>>>>
>>>> That's really misfortunate for such a nice feature! Even more so as
>>>> it is not just theory, but it proves to be working in production
>>>> with JPOX' old implementation of attachCopy().
>>>>
>>>> Regards,
>>>> Jörg
>>>>
>>>> Craig L Russell schrieb:
>>>>> 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
>>>>>
>>>>> On Mar 9, 2006, at 9:48 AM, Jörg von Frantzius wrote:
>>>>>
>>>>>> Craig L Russell schrieb:
>>>>>>> Hi Jörg,
>>>>>>>
>>>>>>> There are no tests planned for this behavior.
>>>>>> That's good ;-)
>>>>>>>
>>>>>>> The issue is that it violates the contract of detachment.
>>>>>>> Detachment is intended to provide a "long-running optimistic
>>>>>>> transaction" in which conflicts are detected in a subsequent
>>>>>>> transaction.
>>>>>> I'd find it a little sad if a great feature like easy replication
>>>>>> was sacrificed in favor of that. Unless replication should be
>>>>>> reserved for JPOX (using a vendor extension), then maybe a future
>>>>>> version of the spec could have something along the lines of the
>>>>>> solution described by Marco in
>>>>>> http://www.jpox.org/servlet/jira/browse/CORE-2741
>>>>>>
>>>>>> That would be great.
>>>>>>
>>>>>> Just for completeness, and maybe it's just me, but the only
>>>>>> sentence about detaching in general that I could find is
>>>>>> "These methods provide a way for an application to identify
>>>>>> persistent instances, obtain
>>>>>> copies of these persistent instances, modify the detached
>>>>>> instances either in the same JVM
>>>>>> or in a different JVM, apply the changes to the same or different
>>>>>> PersistenceManager,
>>>>>> and commit the changes."
>>>>>>
>>>>>> It's not really talking about an equivalent to long-running
>>>>>> optimistic transactions, I find.
>>>>>>> If an instance is detached and then the underlying datastore
>>>>>>> instance is deleted, this is a consistency violation that should
>>>>>>> be detected by the transaction semantics. For example, in an
>>>>>>> order system, if a customer is in a long-running transaction
>>>>>>> with "groovy beads" in the shopping cart, and the administrators
>>>>>>> decide that "groovy beads" are no longer to be sold, you want
>>>>>>> the order that contains "groovy beads" to be rejected when the
>>>>>>> shopping cart arrives at checkout. You don't want that order to
>>>>>>> reinsert "groovy beads" into the database.
>>>>>> I agree that this surely must be catered for.
>>>>>>>
>>>>>>> Craig
>>>>>>>
>>>>>>> On Mar 9, 2006, at 8:40 AM, Jörg von Frantzius wrote:
>>>>>>>
>>>>>>>> Hi Craig,
>>>>>>>>
>>>>>>>> I was already afraid that "create a persistent instance" might
>>>>>>>> only apply to the PM cache, not the datastore (but only after
>>>>>>>> second read). However, would you say that JPOX is not JDO2
>>>>>>>> compliant if it created missing instances in the datastore
>>>>>>>> anyway? Will there be a test in the TCK2 that expects an
>>>>>>>> exception to be thrown if a detached instances does not exist
>>>>>>>> in the datastore?
>>>>>>>>
>>>>>>>> And, most of all, what sense would it make to forbid the
>>>>>>>> creation of missing detached instances in the datastore? There
>>>>>>>> is lots of application for that behaviour, and at least I don't
>>>>>>>> know of any problem with it.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Jörg
>>>>>>>>
>>>>>>>> Craig L Russell schrieb:
>>>>>>>>> Hi Jörg,
>>>>>>>>>
>>>>>>>>> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>>>>>>>>>
>>>>>>>>>> Craig L Russell schrieb:
>>>>>>>>>>>> Also I find it confusing that the method most prominently
>>>>>>>>>>>> used for inserting new objects shouldn't do so for detached
>>>>>>>>>>>> instances.
>>>>>>>>>>>
>>>>>>>>>>> There is a bunch of history that you should look at, most of
>>>>>>>>>>> which is in the jdo-dev archives. Bottom line, we used to
>>>>>>>>>>> have a different API, attachCopy, but we looked at what it
>>>>>>>>>>> had to do for transient and detached instances and decided
>>>>>>>>>>> that it wasn't worth making a different API for attaching
>>>>>>>>>>> detached instances.
>>>>>>>>>> That particular behaviour of attachCopy() wasn't really
>>>>>>>>>> specified, but it was pleasant JPOX-specific behaviour, if I
>>>>>>>>>> remember correctly. I saw the discussion and I didn't see
>>>>>>>>>> where inserting the instances would be forbidden by the spec,
>>>>>>>>>> and still I don't see where it says that, especially in the
>>>>>>>>>> light of 12.6.7. Please excuse my ignorance, where does it
>>>>>>>>>> say that?
>>>>>>>>>
>>>>>>>>> <spec>
>>>>>>>>> These methods make transient instances persistent and apply
>>>>>>>>> detached instance changes
>>>>>>>>> to the cache.
>>>>>>>>> ...
>>>>>>>>> For a detached instance, they locate or create a persistent
>>>>>>>>> instance with the same JDO identity as the detached instance,
>>>>>>>>> and merge the persistent
>>>>>>>>> state of the detached instance into the persistent instance.
>>>>>>>>> Only the state of persistent fields
>>>>>>>>> is merged.
>>>>>>>>> </spec>
>>>>>>>>>
>>>>>>>>> This means that if there is already a persistent instance in
>>>>>>>>> the cache with the same object id as the detached instance,
>>>>>>>>> the detached state will be merged. If there is not a
>>>>>>>>> persistent instance in the cache, a cache instance is created
>>>>>>>>> and the detached state is merged with the persistent instance.
>>>>>>>>>
>>>>>>>>> But there is no creation aspect of makePersistent on a
>>>>>>>>> detached instance.
>>>>>>>>>
>>>>>>>>> Craig
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Craig
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Craig
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What happens when we invoke makePersistent on a detached
>>>>>>>>>>>>>> instance that was
>>>>>>>>>>>>>> deleted by another isolated process? I suspect that we
>>>>>>>>>>>>>> raise an exception
>>>>>>>>>>>>>> instead of reinserting it for a second time. Is that right?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe this can be clarified in the spec.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Craig Russell
>>>>>>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Craig Russell
>>>>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Craig Russell
>>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Craig Russell
>>>>>>> Architect, Sun Java Enterprise System
>>>>>>> http://java.sun.com/products/jdo
>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>
>>>>>>
>>>>>
>>>>> Craig Russell
>>>>> Architect, Sun Java Enterprise System
>>>>> http://java.sun.com/products/jdo
>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>
Re: makePersistent detached instance deleted on database
Posted by Craig L Russell <Cr...@Sun.COM>.
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?
Is bidirectional update supported?
Does it support application identity as well as datastore identity?
Is versioning supported?
Is there a need for user-written callbacks in case of version failure?
It appears from the description of your proposed feature enhancements
that you're only covering master/slave, application identity, no
versioning, no bidirectional update.
Craig
On Mar 10, 2006, at 9:22 AM, Jörg von Frantzius wrote:
> Hi Craig,
>
> sorry I didn't understand what you wanted to see here exactly.
> Maybe something like this:
>
> Replication does work perfectly with detaching using an attachCopy
> () that inserts new instances, and it does so in a productive
> environment using an older JPOX version, however compliant with the
> spec that was.
>
> With the current specification, there is one thinkable approach
> that might work (as pointed out by Matthew), and it has two
> drawbacks. Here's what it could look like:
> Object detachedGraph = pm1.detachCopy(root);
> try {
> pm2.makePersistent(detachedGraph);
> } catch (whatever Exception it is exactly) {
> Collection failedInstances = ... // failed are contained in
> exception
> // find out the original instances of the failed detached
> instances
> Collection originalFailedInstances;
> for (Object failed: failedInstances) {
> Object originalFailed = pm1.getObjectById
> (JDOHelper.getObjectId(failed));
> originalFailedInstances.add(originalFailed);
> }
> pm1.makeTransientAll(originalFailedInstances);
> pm2.makePersistentAll(originalFailedInstances);
> // now that the new objects are made persistent, this should
> succeed:
> pm2.makePersistent(detachedGraph);
> }
> The drawbacks are:
> it won't work for datastore identity, as the identities of the
> instances new to the second PM/datastore are lost upon makeTransient
> (), and there is no reliable way to assure that they will be
> assigned the same identities upon makePersistent() on the second PM,
> it certainly is not very effective.
> The remedy could be the approach proposed by Marco: to have an
> additional method
> PersistenceManager.makePersistent(Object o, boolean insertNew)
> and to have PersistenceManager.makePersistent(Object) default to
> PersistenceManager.makePersistent(o, false).
>
> Regards,
> Jörg
>
> Craig L Russell schrieb:
>> Hi Jörg,
>>
>> As I said earlier, I'd like to see the details of using this
>> feature for replication. What cases are covered, what cases are
>> still problematic, what modifications to the specification are
>> needed in order to accomplish the task?
>>
>> Craig
>>
>> On Mar 10, 2006, at 3:14 AM, Jörg von Frantzius wrote:
>>
>>> Hi Craig,
>>>
>>> replication really is lost in a specification gap: makePersistent
>>> () on transient instances won't update existing data, and on
>>> detached instances it won't insert new. For replication, you need
>>> both behaviours at the same time.
>>>
>>> That's really misfortunate for such a nice feature! Even more so
>>> as it is not just theory, but it proves to be working in
>>> production with JPOX' old implementation of attachCopy().
>>>
>>> Regards,
>>> Jörg
>>>
>>> Craig L Russell schrieb:
>>>> 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
>>>>
>>>> On Mar 9, 2006, at 9:48 AM, Jörg von Frantzius wrote:
>>>>
>>>>> Craig L Russell schrieb:
>>>>>> Hi Jörg,
>>>>>>
>>>>>> There are no tests planned for this behavior.
>>>>> That's good ;-)
>>>>>>
>>>>>> The issue is that it violates the contract of detachment.
>>>>>> Detachment is intended to provide a "long-running optimistic
>>>>>> transaction" in which conflicts are detected in a subsequent
>>>>>> transaction.
>>>>> I'd find it a little sad if a great feature like easy
>>>>> replication was sacrificed in favor of that. Unless replication
>>>>> should be reserved for JPOX (using a vendor extension), then
>>>>> maybe a future version of the spec could have something along
>>>>> the lines of the solution described by Marco in http://
>>>>> www.jpox.org/servlet/jira/browse/CORE-2741
>>>>>
>>>>> That would be great.
>>>>>
>>>>> Just for completeness, and maybe it's just me, but the only
>>>>> sentence about detaching in general that I could find is
>>>>> "These methods provide a way for an application to identify
>>>>> persistent instances, obtain
>>>>> copies of these persistent instances, modify the detached
>>>>> instances either in the same JVM
>>>>> or in a different JVM, apply the changes to the same or
>>>>> different PersistenceManager,
>>>>> and commit the changes."
>>>>>
>>>>> It's not really talking about an equivalent to long-running
>>>>> optimistic transactions, I find.
>>>>>> If an instance is detached and then the underlying datastore
>>>>>> instance is deleted, this is a consistency violation that
>>>>>> should be detected by the transaction semantics. For example,
>>>>>> in an order system, if a customer is in a long-running
>>>>>> transaction with "groovy beads" in the shopping cart, and the
>>>>>> administrators decide that "groovy beads" are no longer to be
>>>>>> sold, you want the order that contains "groovy beads" to be
>>>>>> rejected when the shopping cart arrives at checkout. You don't
>>>>>> want that order to reinsert "groovy beads" into the database.
>>>>> I agree that this surely must be catered for.
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>> On Mar 9, 2006, at 8:40 AM, Jörg von Frantzius wrote:
>>>>>>
>>>>>>> Hi Craig,
>>>>>>>
>>>>>>> I was already afraid that "create a persistent instance"
>>>>>>> might only apply to the PM cache, not the datastore (but only
>>>>>>> after second read). However, would you say that JPOX is not
>>>>>>> JDO2 compliant if it created missing instances in the
>>>>>>> datastore anyway? Will there be a test in the TCK2 that
>>>>>>> expects an exception to be thrown if a detached instances
>>>>>>> does not exist in the datastore?
>>>>>>>
>>>>>>> And, most of all, what sense would it make to forbid the
>>>>>>> creation of missing detached instances in the datastore?
>>>>>>> There is lots of application for that behaviour, and at least
>>>>>>> I don't know of any problem with it.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jörg
>>>>>>>
>>>>>>> Craig L Russell schrieb:
>>>>>>>> Hi Jörg,
>>>>>>>>
>>>>>>>> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>>>>>>>>
>>>>>>>>> Craig L Russell schrieb:
>>>>>>>>>>> Also I find it confusing that the method most prominently
>>>>>>>>>>> used for inserting new objects shouldn't do so for
>>>>>>>>>>> detached instances.
>>>>>>>>>>
>>>>>>>>>> There is a bunch of history that you should look at, most
>>>>>>>>>> of which is in the jdo-dev archives. Bottom line, we used
>>>>>>>>>> to have a different API, attachCopy, but we looked at what
>>>>>>>>>> it had to do for transient and detached instances and
>>>>>>>>>> decided that it wasn't worth making a different API for
>>>>>>>>>> attaching detached instances.
>>>>>>>>> That particular behaviour of attachCopy() wasn't really
>>>>>>>>> specified, but it was pleasant JPOX-specific behaviour, if
>>>>>>>>> I remember correctly. I saw the discussion and I didn't see
>>>>>>>>> where inserting the instances would be forbidden by the
>>>>>>>>> spec, and still I don't see where it says that, especially
>>>>>>>>> in the light of 12.6.7. Please excuse my ignorance, where
>>>>>>>>> does it say that?
>>>>>>>>
>>>>>>>> <spec>
>>>>>>>> These methods make transient instances persistent and apply
>>>>>>>> detached instance changes
>>>>>>>> to the cache.
>>>>>>>> ...
>>>>>>>> For a detached instance, they locate or create a persistent
>>>>>>>> instance with the same JDO identity as the detached
>>>>>>>> instance, and merge the persistent
>>>>>>>> state of the detached instance into the persistent instance.
>>>>>>>> Only the state of persistent fields
>>>>>>>> is merged.
>>>>>>>> </spec>
>>>>>>>>
>>>>>>>> This means that if there is already a persistent instance in
>>>>>>>> the cache with the same object id as the detached instance,
>>>>>>>> the detached state will be merged. If there is not a
>>>>>>>> persistent instance in the cache, a cache instance is
>>>>>>>> created and the detached state is merged with the persistent
>>>>>>>> instance.
>>>>>>>>
>>>>>>>> But there is no creation aspect of makePersistent on a
>>>>>>>> detached instance.
>>>>>>>>
>>>>>>>> Craig
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Craig
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Craig
>>>>>>>>>>>>
>>>>>>>>>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> What happens when we invoke makePersistent on a
>>>>>>>>>>>>> detached instance that was
>>>>>>>>>>>>> deleted by another isolated process? I suspect that we
>>>>>>>>>>>>> raise an exception
>>>>>>>>>>>>> instead of reinserting it for a second time. Is that
>>>>>>>>>>>>> right?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe this can be clarified in the spec.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Craig Russell
>>>>>>>>>>>> Architect, Sun Java Enterprise System http://
>>>>>>>>>>>> java.sun.com/products/jdo
>>>>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Craig Russell
>>>>>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>>>>>>> products/jdo
>>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Craig Russell
>>>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>>>>> products/jdo
>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Craig Russell
>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>>> products/jdo
>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>>
>>>>
>>>> Craig Russell
>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>> products/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: makePersistent detached instance deleted on database
Posted by Jörg von Frantzius <jo...@artnology.com>.
Hi Craig,
sorry I didn't understand what you wanted to see here exactly. Maybe
something like this:
Replication does work perfectly with detaching using an attachCopy()
that inserts new instances, and it does so in a productive environment
using an older JPOX version, however compliant with the spec that was.
With the current specification, there is one thinkable approach that
might work (as pointed out by Matthew), and it has two drawbacks. Here's
what it could look like:
Object detachedGraph = pm1.detachCopy(root);
try {
pm2.makePersistent(detachedGraph);
} catch (whatever Exception it is exactly) {
Collection failedInstances = ... // failed are contained in exception
// find out the original instances of the failed detached instances
Collection originalFailedInstances;
for (Object failed: failedInstances) {
Object originalFailed = pm1.getObjectById(JDOHelper.getObjectId(failed));
originalFailedInstances.add(originalFailed);
}
pm1.makeTransientAll(originalFailedInstances);
pm2.makePersistentAll(originalFailedInstances);
// now that the new objects are made persistent, this should succeed:
pm2.makePersistent(detachedGraph);
}
The drawbacks are:
1. it *won't work for datastore identity*, as the identities of the
instances new to the second PM/datastore are lost upon
makeTransient(), and there is no reliable way to assure that they
will be assigned the same identities upon makePersistent() on the
second PM,
2. it certainly is *not very effective*.
The remedy could be the approach proposed by Marco: to have an
additional method
PersistenceManager.makePersistent(Object o, boolean insertNew)
and to have PersistenceManager.makePersistent(Object) default to
PersistenceManager.makePersistent(o, false).
Regards,
Jörg
Craig L Russell schrieb:
> Hi Jörg,
>
> As I said earlier, I'd like to see the details of using this feature
> for replication. What cases are covered, what cases are still
> problematic, what modifications to the specification are needed in
> order to accomplish the task?
>
> Craig
>
> On Mar 10, 2006, at 3:14 AM, Jörg von Frantzius wrote:
>
>> Hi Craig,
>>
>> replication really is lost in a specification gap: makePersistent()
>> on transient instances won't update existing data, and on detached
>> instances it won't insert new. For replication, you need both
>> behaviours at the same time.
>>
>> That's really misfortunate for such a nice feature! Even more so as
>> it is not just theory, but it proves to be working in production with
>> JPOX' old implementation of attachCopy().
>>
>> Regards,
>> Jörg
>>
>> Craig L Russell schrieb:
>>> 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
>>>
>>> On Mar 9, 2006, at 9:48 AM, Jörg von Frantzius wrote:
>>>
>>>> Craig L Russell schrieb:
>>>>> Hi Jörg,
>>>>>
>>>>> There are no tests planned for this behavior.
>>>> That's good ;-)
>>>>>
>>>>> The issue is that it violates the contract of detachment.
>>>>> Detachment is intended to provide a "long-running optimistic
>>>>> transaction" in which conflicts are detected in a subsequent
>>>>> transaction.
>>>> I'd find it a little sad if a great feature like easy replication
>>>> was sacrificed in favor of that. Unless replication should be
>>>> reserved for JPOX (using a vendor extension), then maybe a future
>>>> version of the spec could have something along the lines of the
>>>> solution described by Marco in
>>>> http://www.jpox.org/servlet/jira/browse/CORE-2741
>>>>
>>>> That would be great.
>>>>
>>>> Just for completeness, and maybe it's just me, but the only
>>>> sentence about detaching in general that I could find is
>>>> "These methods provide a way for an application to identify
>>>> persistent instances, obtain
>>>> copies of these persistent instances, modify the detached instances
>>>> either in the same JVM
>>>> or in a different JVM, apply the changes to the same or different
>>>> PersistenceManager,
>>>> and commit the changes."
>>>>
>>>> It's not really talking about an equivalent to long-running
>>>> optimistic transactions, I find.
>>>>> If an instance is detached and then the underlying datastore
>>>>> instance is deleted, this is a consistency violation that should
>>>>> be detected by the transaction semantics. For example, in an order
>>>>> system, if a customer is in a long-running transaction with
>>>>> "groovy beads" in the shopping cart, and the administrators decide
>>>>> that "groovy beads" are no longer to be sold, you want the order
>>>>> that contains "groovy beads" to be rejected when the shopping cart
>>>>> arrives at checkout. You don't want that order to reinsert "groovy
>>>>> beads" into the database.
>>>> I agree that this surely must be catered for.
>>>>>
>>>>> Craig
>>>>>
>>>>> On Mar 9, 2006, at 8:40 AM, Jörg von Frantzius wrote:
>>>>>
>>>>>> Hi Craig,
>>>>>>
>>>>>> I was already afraid that "create a persistent instance" might
>>>>>> only apply to the PM cache, not the datastore (but only after
>>>>>> second read). However, would you say that JPOX is not JDO2
>>>>>> compliant if it created missing instances in the datastore
>>>>>> anyway? Will there be a test in the TCK2 that expects an
>>>>>> exception to be thrown if a detached instances does not exist in
>>>>>> the datastore?
>>>>>>
>>>>>> And, most of all, what sense would it make to forbid the creation
>>>>>> of missing detached instances in the datastore? There is lots of
>>>>>> application for that behaviour, and at least I don't know of any
>>>>>> problem with it.
>>>>>>
>>>>>> Regards,
>>>>>> Jörg
>>>>>>
>>>>>> Craig L Russell schrieb:
>>>>>>> Hi Jörg,
>>>>>>>
>>>>>>> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>>>>>>>
>>>>>>>> Craig L Russell schrieb:
>>>>>>>>>> Also I find it confusing that the method most prominently
>>>>>>>>>> used for inserting new objects shouldn't do so for detached
>>>>>>>>>> instances.
>>>>>>>>>
>>>>>>>>> There is a bunch of history that you should look at, most of
>>>>>>>>> which is in the jdo-dev archives. Bottom line, we used to have
>>>>>>>>> a different API, attachCopy, but we looked at what it had to
>>>>>>>>> do for transient and detached instances and decided that it
>>>>>>>>> wasn't worth making a different API for attaching detached
>>>>>>>>> instances.
>>>>>>>> That particular behaviour of attachCopy() wasn't really
>>>>>>>> specified, but it was pleasant JPOX-specific behaviour, if I
>>>>>>>> remember correctly. I saw the discussion and I didn't see where
>>>>>>>> inserting the instances would be forbidden by the spec, and
>>>>>>>> still I don't see where it says that, especially in the light
>>>>>>>> of 12.6.7. Please excuse my ignorance, where does it say that?
>>>>>>>
>>>>>>> <spec>
>>>>>>> These methods make transient instances persistent and apply
>>>>>>> detached instance changes
>>>>>>> to the cache.
>>>>>>> ...
>>>>>>> For a detached instance, they locate or create a persistent
>>>>>>> instance with the same JDO identity as the detached instance,
>>>>>>> and merge the persistent
>>>>>>> state of the detached instance into the persistent instance.
>>>>>>> Only the state of persistent fields
>>>>>>> is merged.
>>>>>>> </spec>
>>>>>>>
>>>>>>> This means that if there is already a persistent instance in the
>>>>>>> cache with the same object id as the detached instance, the
>>>>>>> detached state will be merged. If there is not a persistent
>>>>>>> instance in the cache, a cache instance is created and the
>>>>>>> detached state is merged with the persistent instance.
>>>>>>>
>>>>>>> But there is no creation aspect of makePersistent on a detached
>>>>>>> instance.
>>>>>>>
>>>>>>> Craig
>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Craig
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Craig
>>>>>>>>>>>
>>>>>>>>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> What happens when we invoke makePersistent on a detached
>>>>>>>>>>>> instance that was
>>>>>>>>>>>> deleted by another isolated process? I suspect that we
>>>>>>>>>>>> raise an exception
>>>>>>>>>>>> instead of reinserting it for a second time. Is that right?
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe this can be clarified in the spec.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Craig Russell
>>>>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Craig Russell
>>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Craig Russell
>>>>>>> Architect, Sun Java Enterprise System
>>>>>>> http://java.sun.com/products/jdo
>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>
>>>>>>
>>>>>
>>>>> Craig Russell
>>>>> Architect, Sun Java Enterprise System
>>>>> http://java.sun.com/products/jdo
>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: makePersistent detached instance deleted on database
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Jörg,
As I said earlier, I'd like to see the details of using this feature
for replication. What cases are covered, what cases are still
problematic, what modifications to the specification are needed in
order to accomplish the task?
Craig
On Mar 10, 2006, at 3:14 AM, Jörg von Frantzius wrote:
> Hi Craig,
>
> replication really is lost in a specification gap: makePersistent()
> on transient instances won't update existing data, and on detached
> instances it won't insert new. For replication, you need both
> behaviours at the same time.
>
> That's really misfortunate for such a nice feature! Even more so as
> it is not just theory, but it proves to be working in production
> with JPOX' old implementation of attachCopy().
>
> Regards,
> Jörg
>
> Craig L Russell schrieb:
>> 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
>>
>> On Mar 9, 2006, at 9:48 AM, Jörg von Frantzius wrote:
>>
>>> Craig L Russell schrieb:
>>>> Hi Jörg,
>>>>
>>>> There are no tests planned for this behavior.
>>> That's good ;-)
>>>>
>>>> The issue is that it violates the contract of detachment.
>>>> Detachment is intended to provide a "long-running optimistic
>>>> transaction" in which conflicts are detected in a subsequent
>>>> transaction.
>>> I'd find it a little sad if a great feature like easy replication
>>> was sacrificed in favor of that. Unless replication should be
>>> reserved for JPOX (using a vendor extension), then maybe a future
>>> version of the spec could have something along the lines of the
>>> solution described by Marco in http://www.jpox.org/servlet/jira/
>>> browse/CORE-2741
>>>
>>> That would be great.
>>>
>>> Just for completeness, and maybe it's just me, but the only
>>> sentence about detaching in general that I could find is
>>> "These methods provide a way for an application to identify
>>> persistent instances, obtain
>>> copies of these persistent instances, modify the detached
>>> instances either in the same JVM
>>> or in a different JVM, apply the changes to the same or different
>>> PersistenceManager,
>>> and commit the changes."
>>>
>>> It's not really talking about an equivalent to long-running
>>> optimistic transactions, I find.
>>>> If an instance is detached and then the underlying datastore
>>>> instance is deleted, this is a consistency violation that should
>>>> be detected by the transaction semantics. For example, in an
>>>> order system, if a customer is in a long-running transaction
>>>> with "groovy beads" in the shopping cart, and the administrators
>>>> decide that "groovy beads" are no longer to be sold, you want
>>>> the order that contains "groovy beads" to be rejected when the
>>>> shopping cart arrives at checkout. You don't want that order to
>>>> reinsert "groovy beads" into the database.
>>> I agree that this surely must be catered for.
>>>>
>>>> Craig
>>>>
>>>> On Mar 9, 2006, at 8:40 AM, Jörg von Frantzius wrote:
>>>>
>>>>> Hi Craig,
>>>>>
>>>>> I was already afraid that "create a persistent instance" might
>>>>> only apply to the PM cache, not the datastore (but only after
>>>>> second read). However, would you say that JPOX is not JDO2
>>>>> compliant if it created missing instances in the datastore
>>>>> anyway? Will there be a test in the TCK2 that expects an
>>>>> exception to be thrown if a detached instances does not exist
>>>>> in the datastore?
>>>>>
>>>>> And, most of all, what sense would it make to forbid the
>>>>> creation of missing detached instances in the datastore? There
>>>>> is lots of application for that behaviour, and at least I don't
>>>>> know of any problem with it.
>>>>>
>>>>> Regards,
>>>>> Jörg
>>>>>
>>>>> Craig L Russell schrieb:
>>>>>> Hi Jörg,
>>>>>>
>>>>>> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>>>>>>
>>>>>>> Craig L Russell schrieb:
>>>>>>>>> Also I find it confusing that the method most prominently
>>>>>>>>> used for inserting new objects shouldn't do so for detached
>>>>>>>>> instances.
>>>>>>>>
>>>>>>>> There is a bunch of history that you should look at, most of
>>>>>>>> which is in the jdo-dev archives. Bottom line, we used to
>>>>>>>> have a different API, attachCopy, but we looked at what it
>>>>>>>> had to do for transient and detached instances and decided
>>>>>>>> that it wasn't worth making a different API for attaching
>>>>>>>> detached instances.
>>>>>>> That particular behaviour of attachCopy() wasn't really
>>>>>>> specified, but it was pleasant JPOX-specific behaviour, if I
>>>>>>> remember correctly. I saw the discussion and I didn't see
>>>>>>> where inserting the instances would be forbidden by the spec,
>>>>>>> and still I don't see where it says that, especially in the
>>>>>>> light of 12.6.7. Please excuse my ignorance, where does it
>>>>>>> say that?
>>>>>>
>>>>>> <spec>
>>>>>> These methods make transient instances persistent and apply
>>>>>> detached instance changes
>>>>>> to the cache.
>>>>>> ...
>>>>>> For a detached instance, they locate or create a persistent
>>>>>> instance with the same JDO identity as the detached instance,
>>>>>> and merge the persistent
>>>>>> state of the detached instance into the persistent instance.
>>>>>> Only the state of persistent fields
>>>>>> is merged.
>>>>>> </spec>
>>>>>>
>>>>>> This means that if there is already a persistent instance in
>>>>>> the cache with the same object id as the detached instance,
>>>>>> the detached state will be merged. If there is not a
>>>>>> persistent instance in the cache, a cache instance is created
>>>>>> and the detached state is merged with the persistent instance.
>>>>>>
>>>>>> But there is no creation aspect of makePersistent on a
>>>>>> detached instance.
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Craig
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Craig
>>>>>>>>>>
>>>>>>>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> What happens when we invoke makePersistent on a detached
>>>>>>>>>>> instance that was
>>>>>>>>>>> deleted by another isolated process? I suspect that we
>>>>>>>>>>> raise an exception
>>>>>>>>>>> instead of reinserting it for a second time. Is that right?
>>>>>>>>>>>
>>>>>>>>>>> Maybe this can be clarified in the spec.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Craig Russell
>>>>>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>>>>>>> products/jdo
>>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Craig Russell
>>>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>>>>> products/jdo
>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Craig Russell
>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>>> products/jdo
>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>>
>>>>
>>>> Craig Russell
>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>> products/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: makePersistent detached instance deleted on database
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Jörg,
Sorry I lost this message in email limbo, but I am serious. Please
consider writing a proposal on adding methods to better support
replication. Two-paragraph email messages are not the level of detail
we need to consider. How about a proposal?
Thanks,
Craig
On Mar 10, 2006, at 3:14 AM, Jörg von Frantzius wrote:
> Hi Craig,
>
> replication really is lost in a specification gap: makePersistent()
> on transient instances won't update existing data, and on detached
> instances it won't insert new. For replication, you need both
> behaviours at the same time.
>
> That's really misfortunate for such a nice feature! Even more so as
> it is not just theory, but it proves to be working in production
> with JPOX' old implementation of attachCopy().
>
> Regards,
> Jörg
>
> Craig L Russell schrieb:
>> 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
>>
>> On Mar 9, 2006, at 9:48 AM, Jörg von Frantzius wrote:
>>
>>> Craig L Russell schrieb:
>>>> Hi Jörg,
>>>>
>>>> There are no tests planned for this behavior.
>>> That's good ;-)
>>>>
>>>> The issue is that it violates the contract of detachment.
>>>> Detachment is intended to provide a "long-running optimistic
>>>> transaction" in which conflicts are detected in a subsequent
>>>> transaction.
>>> I'd find it a little sad if a great feature like easy replication
>>> was sacrificed in favor of that. Unless replication should be
>>> reserved for JPOX (using a vendor extension), then maybe a future
>>> version of the spec could have something along the lines of the
>>> solution described by Marco in http://www.jpox.org/servlet/jira/
>>> browse/CORE-2741
>>>
>>> That would be great.
>>>
>>> Just for completeness, and maybe it's just me, but the only
>>> sentence about detaching in general that I could find is
>>> "These methods provide a way for an application to identify
>>> persistent instances, obtain
>>> copies of these persistent instances, modify the detached
>>> instances either in the same JVM
>>> or in a different JVM, apply the changes to the same or different
>>> PersistenceManager,
>>> and commit the changes."
>>>
>>> It's not really talking about an equivalent to long-running
>>> optimistic transactions, I find.
>>>> If an instance is detached and then the underlying datastore
>>>> instance is deleted, this is a consistency violation that should
>>>> be detected by the transaction semantics. For example, in an
>>>> order system, if a customer is in a long-running transaction
>>>> with "groovy beads" in the shopping cart, and the administrators
>>>> decide that "groovy beads" are no longer to be sold, you want
>>>> the order that contains "groovy beads" to be rejected when the
>>>> shopping cart arrives at checkout. You don't want that order to
>>>> reinsert "groovy beads" into the database.
>>> I agree that this surely must be catered for.
>>>>
>>>> Craig
>>>>
>>>> On Mar 9, 2006, at 8:40 AM, Jörg von Frantzius wrote:
>>>>
>>>>> Hi Craig,
>>>>>
>>>>> I was already afraid that "create a persistent instance" might
>>>>> only apply to the PM cache, not the datastore (but only after
>>>>> second read). However, would you say that JPOX is not JDO2
>>>>> compliant if it created missing instances in the datastore
>>>>> anyway? Will there be a test in the TCK2 that expects an
>>>>> exception to be thrown if a detached instances does not exist
>>>>> in the datastore?
>>>>>
>>>>> And, most of all, what sense would it make to forbid the
>>>>> creation of missing detached instances in the datastore? There
>>>>> is lots of application for that behaviour, and at least I don't
>>>>> know of any problem with it.
>>>>>
>>>>> Regards,
>>>>> Jörg
>>>>>
>>>>> Craig L Russell schrieb:
>>>>>> Hi Jörg,
>>>>>>
>>>>>> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>>>>>>
>>>>>>> Craig L Russell schrieb:
>>>>>>>>> Also I find it confusing that the method most prominently
>>>>>>>>> used for inserting new objects shouldn't do so for detached
>>>>>>>>> instances.
>>>>>>>>
>>>>>>>> There is a bunch of history that you should look at, most of
>>>>>>>> which is in the jdo-dev archives. Bottom line, we used to
>>>>>>>> have a different API, attachCopy, but we looked at what it
>>>>>>>> had to do for transient and detached instances and decided
>>>>>>>> that it wasn't worth making a different API for attaching
>>>>>>>> detached instances.
>>>>>>> That particular behaviour of attachCopy() wasn't really
>>>>>>> specified, but it was pleasant JPOX-specific behaviour, if I
>>>>>>> remember correctly. I saw the discussion and I didn't see
>>>>>>> where inserting the instances would be forbidden by the spec,
>>>>>>> and still I don't see where it says that, especially in the
>>>>>>> light of 12.6.7. Please excuse my ignorance, where does it
>>>>>>> say that?
>>>>>>
>>>>>> <spec>
>>>>>> These methods make transient instances persistent and apply
>>>>>> detached instance changes
>>>>>> to the cache.
>>>>>> ...
>>>>>> For a detached instance, they locate or create a persistent
>>>>>> instance with the same JDO identity as the detached instance,
>>>>>> and merge the persistent
>>>>>> state of the detached instance into the persistent instance.
>>>>>> Only the state of persistent fields
>>>>>> is merged.
>>>>>> </spec>
>>>>>>
>>>>>> This means that if there is already a persistent instance in
>>>>>> the cache with the same object id as the detached instance,
>>>>>> the detached state will be merged. If there is not a
>>>>>> persistent instance in the cache, a cache instance is created
>>>>>> and the detached state is merged with the persistent instance.
>>>>>>
>>>>>> But there is no creation aspect of makePersistent on a
>>>>>> detached instance.
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Craig
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Craig
>>>>>>>>>>
>>>>>>>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> What happens when we invoke makePersistent on a detached
>>>>>>>>>>> instance that was
>>>>>>>>>>> deleted by another isolated process? I suspect that we
>>>>>>>>>>> raise an exception
>>>>>>>>>>> instead of reinserting it for a second time. Is that right?
>>>>>>>>>>>
>>>>>>>>>>> Maybe this can be clarified in the spec.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Craig Russell
>>>>>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>>>>>>> products/jdo
>>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Craig Russell
>>>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>>>>> products/jdo
>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Craig Russell
>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>>> products/jdo
>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>>
>>>>
>>>> Craig Russell
>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>> products/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Re: makePersistent detached instance deleted on database
Posted by Jörg von Frantzius <jo...@artnology.com>.
Hi Craig,
replication really is lost in a specification gap: makePersistent() on
transient instances won't update existing data, and on detached
instances it won't insert new. For replication, you need both behaviours
at the same time.
That's really misfortunate for such a nice feature! Even more so as it
is not just theory, but it proves to be working in production with JPOX'
old implementation of attachCopy().
Regards,
Jörg
Craig L Russell schrieb:
> 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
>
> On Mar 9, 2006, at 9:48 AM, Jörg von Frantzius wrote:
>
>> Craig L Russell schrieb:
>>> Hi Jörg,
>>>
>>> There are no tests planned for this behavior.
>> That's good ;-)
>>>
>>> The issue is that it violates the contract of detachment. Detachment
>>> is intended to provide a "long-running optimistic transaction" in
>>> which conflicts are detected in a subsequent transaction.
>> I'd find it a little sad if a great feature like easy replication was
>> sacrificed in favor of that. Unless replication should be reserved
>> for JPOX (using a vendor extension), then maybe a future version of
>> the spec could have something along the lines of the solution
>> described by Marco in http://www.jpox.org/servlet/jira/browse/CORE-2741
>>
>> That would be great.
>>
>> Just for completeness, and maybe it's just me, but the only sentence
>> about detaching in general that I could find is
>> "These methods provide a way for an application to identify
>> persistent instances, obtain
>> copies of these persistent instances, modify the detached instances
>> either in the same JVM
>> or in a different JVM, apply the changes to the same or different
>> PersistenceManager,
>> and commit the changes."
>>
>> It's not really talking about an equivalent to long-running
>> optimistic transactions, I find.
>>> If an instance is detached and then the underlying datastore
>>> instance is deleted, this is a consistency violation that should be
>>> detected by the transaction semantics. For example, in an order
>>> system, if a customer is in a long-running transaction with "groovy
>>> beads" in the shopping cart, and the administrators decide that
>>> "groovy beads" are no longer to be sold, you want the order that
>>> contains "groovy beads" to be rejected when the shopping cart
>>> arrives at checkout. You don't want that order to reinsert "groovy
>>> beads" into the database.
>> I agree that this surely must be catered for.
>>>
>>> Craig
>>>
>>> On Mar 9, 2006, at 8:40 AM, Jörg von Frantzius wrote:
>>>
>>>> Hi Craig,
>>>>
>>>> I was already afraid that "create a persistent instance" might only
>>>> apply to the PM cache, not the datastore (but only after second
>>>> read). However, would you say that JPOX is not JDO2 compliant if it
>>>> created missing instances in the datastore anyway? Will there be a
>>>> test in the TCK2 that expects an exception to be thrown if a
>>>> detached instances does not exist in the datastore?
>>>>
>>>> And, most of all, what sense would it make to forbid the creation
>>>> of missing detached instances in the datastore? There is lots of
>>>> application for that behaviour, and at least I don't know of any
>>>> problem with it.
>>>>
>>>> Regards,
>>>> Jörg
>>>>
>>>> Craig L Russell schrieb:
>>>>> Hi Jörg,
>>>>>
>>>>> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>>>>>
>>>>>> Craig L Russell schrieb:
>>>>>>>> Also I find it confusing that the method most prominently used
>>>>>>>> for inserting new objects shouldn't do so for detached instances.
>>>>>>>
>>>>>>> There is a bunch of history that you should look at, most of
>>>>>>> which is in the jdo-dev archives. Bottom line, we used to have a
>>>>>>> different API, attachCopy, but we looked at what it had to do
>>>>>>> for transient and detached instances and decided that it wasn't
>>>>>>> worth making a different API for attaching detached instances.
>>>>>> That particular behaviour of attachCopy() wasn't really
>>>>>> specified, but it was pleasant JPOX-specific behaviour, if I
>>>>>> remember correctly. I saw the discussion and I didn't see where
>>>>>> inserting the instances would be forbidden by the spec, and still
>>>>>> I don't see where it says that, especially in the light of
>>>>>> 12.6.7. Please excuse my ignorance, where does it say that?
>>>>>
>>>>> <spec>
>>>>> These methods make transient instances persistent and apply
>>>>> detached instance changes
>>>>> to the cache.
>>>>> ...
>>>>> For a detached instance, they locate or create a persistent
>>>>> instance with the same JDO identity as the detached instance, and
>>>>> merge the persistent
>>>>> state of the detached instance into the persistent instance. Only
>>>>> the state of persistent fields
>>>>> is merged.
>>>>> </spec>
>>>>>
>>>>> This means that if there is already a persistent instance in the
>>>>> cache with the same object id as the detached instance, the
>>>>> detached state will be merged. If there is not a persistent
>>>>> instance in the cache, a cache instance is created and the
>>>>> detached state is merged with the persistent instance.
>>>>>
>>>>> But there is no creation aspect of makePersistent on a detached
>>>>> instance.
>>>>>
>>>>> Craig
>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Craig
>>>>>>>
>>>>>>>>>
>>>>>>>>> Craig
>>>>>>>>>
>>>>>>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> What happens when we invoke makePersistent on a detached
>>>>>>>>>> instance that was
>>>>>>>>>> deleted by another isolated process? I suspect that we raise
>>>>>>>>>> an exception
>>>>>>>>>> instead of reinserting it for a second time. Is that right?
>>>>>>>>>>
>>>>>>>>>> Maybe this can be clarified in the spec.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Craig Russell
>>>>>>>>> Architect, Sun Java Enterprise System
>>>>>>>>> http://java.sun.com/products/jdo
>>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Craig Russell
>>>>>>> Architect, Sun Java Enterprise System
>>>>>>> http://java.sun.com/products/jdo
>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>
>>>>>>
>>>>>
>>>>> Craig Russell
>>>>> Architect, Sun Java Enterprise System
>>>>> http://java.sun.com/products/jdo
>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: makePersistent detached instance deleted on database
Posted by Craig L Russell <Cr...@Sun.COM>.
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
On Mar 9, 2006, at 9:48 AM, Jörg von Frantzius wrote:
> Craig L Russell schrieb:
>> Hi Jörg,
>>
>> There are no tests planned for this behavior.
> That's good ;-)
>>
>> The issue is that it violates the contract of detachment.
>> Detachment is intended to provide a "long-running optimistic
>> transaction" in which conflicts are detected in a subsequent
>> transaction.
> I'd find it a little sad if a great feature like easy replication
> was sacrificed in favor of that. Unless replication should be
> reserved for JPOX (using a vendor extension), then maybe a future
> version of the spec could have something along the lines of the
> solution described by Marco in http://www.jpox.org/servlet/jira/
> browse/CORE-2741
>
> That would be great.
>
> Just for completeness, and maybe it's just me, but the only
> sentence about detaching in general that I could find is
> "These methods provide a way for an application to identify
> persistent instances, obtain
> copies of these persistent instances, modify the detached instances
> either in the same JVM
> or in a different JVM, apply the changes to the same or different
> PersistenceManager,
> and commit the changes."
>
> It's not really talking about an equivalent to long-running
> optimistic transactions, I find.
>> If an instance is detached and then the underlying datastore
>> instance is deleted, this is a consistency violation that should
>> be detected by the transaction semantics. For example, in an order
>> system, if a customer is in a long-running transaction with
>> "groovy beads" in the shopping cart, and the administrators decide
>> that "groovy beads" are no longer to be sold, you want the order
>> that contains "groovy beads" to be rejected when the shopping cart
>> arrives at checkout. You don't want that order to reinsert "groovy
>> beads" into the database.
> I agree that this surely must be catered for.
>>
>> Craig
>>
>> On Mar 9, 2006, at 8:40 AM, Jörg von Frantzius wrote:
>>
>>> Hi Craig,
>>>
>>> I was already afraid that "create a persistent instance" might
>>> only apply to the PM cache, not the datastore (but only after
>>> second read). However, would you say that JPOX is not JDO2
>>> compliant if it created missing instances in the datastore
>>> anyway? Will there be a test in the TCK2 that expects an
>>> exception to be thrown if a detached instances does not exist in
>>> the datastore?
>>>
>>> And, most of all, what sense would it make to forbid the creation
>>> of missing detached instances in the datastore? There is lots of
>>> application for that behaviour, and at least I don't know of any
>>> problem with it.
>>>
>>> Regards,
>>> Jörg
>>>
>>> Craig L Russell schrieb:
>>>> Hi Jörg,
>>>>
>>>> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>>>>
>>>>> Craig L Russell schrieb:
>>>>>>> Also I find it confusing that the method most prominently
>>>>>>> used for inserting new objects shouldn't do so for detached
>>>>>>> instances.
>>>>>>
>>>>>> There is a bunch of history that you should look at, most of
>>>>>> which is in the jdo-dev archives. Bottom line, we used to have
>>>>>> a different API, attachCopy, but we looked at what it had to
>>>>>> do for transient and detached instances and decided that it
>>>>>> wasn't worth making a different API for attaching detached
>>>>>> instances.
>>>>> That particular behaviour of attachCopy() wasn't really
>>>>> specified, but it was pleasant JPOX-specific behaviour, if I
>>>>> remember correctly. I saw the discussion and I didn't see where
>>>>> inserting the instances would be forbidden by the spec, and
>>>>> still I don't see where it says that, especially in the light
>>>>> of 12.6.7. Please excuse my ignorance, where does it say that?
>>>>
>>>> <spec>
>>>> These methods make transient instances persistent and apply
>>>> detached instance changes
>>>> to the cache.
>>>> ...
>>>> For a detached instance, they locate or create a persistent
>>>> instance with the same JDO identity as the detached instance,
>>>> and merge the persistent
>>>> state of the detached instance into the persistent instance.
>>>> Only the state of persistent fields
>>>> is merged.
>>>> </spec>
>>>>
>>>> This means that if there is already a persistent instance in the
>>>> cache with the same object id as the detached instance, the
>>>> detached state will be merged. If there is not a persistent
>>>> instance in the cache, a cache instance is created and the
>>>> detached state is merged with the persistent instance.
>>>>
>>>> But there is no creation aspect of makePersistent on a detached
>>>> instance.
>>>>
>>>> Craig
>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>>>>
>>>>>>>> Craig
>>>>>>>>
>>>>>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> What happens when we invoke makePersistent on a detached
>>>>>>>>> instance that was
>>>>>>>>> deleted by another isolated process? I suspect that we
>>>>>>>>> raise an exception
>>>>>>>>> instead of reinserting it for a second time. Is that right?
>>>>>>>>>
>>>>>>>>> Maybe this can be clarified in the spec.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Craig Russell
>>>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>>>>> products/jdo
>>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Craig Russell
>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>>> products/jdo
>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>>
>>>>
>>>> Craig Russell
>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>> products/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: makePersistent detached instance deleted on database
Posted by Jörg von Frantzius <jo...@artnology.com>.
Craig L Russell schrieb:
> Hi Jörg,
>
> There are no tests planned for this behavior.
That's good ;-)
>
> The issue is that it violates the contract of detachment. Detachment
> is intended to provide a "long-running optimistic transaction" in
> which conflicts are detected in a subsequent transaction.
I'd find it a little sad if a great feature like easy replication was
sacrificed in favor of that. Unless replication should be reserved for
JPOX (using a vendor extension), then maybe a future version of the spec
could have something along the lines of the solution described by Marco
in http://www.jpox.org/servlet/jira/browse/CORE-2741
That would be great.
Just for completeness, and maybe it's just me, but the only sentence
about detaching in general that I could find is
"These methods provide a way for an application to identify persistent
instances, obtain
copies of these persistent instances, modify the detached instances
either in the same JVM
or in a different JVM, apply the changes to the same or different
PersistenceManager,
and commit the changes."
It's not really talking about an equivalent to long-running optimistic
transactions, I find.
> If an instance is detached and then the underlying datastore instance
> is deleted, this is a consistency violation that should be detected by
> the transaction semantics. For example, in an order system, if a
> customer is in a long-running transaction with "groovy beads" in the
> shopping cart, and the administrators decide that "groovy beads" are
> no longer to be sold, you want the order that contains "groovy beads"
> to be rejected when the shopping cart arrives at checkout. You don't
> want that order to reinsert "groovy beads" into the database.
I agree that this surely must be catered for.
>
> Craig
>
> On Mar 9, 2006, at 8:40 AM, Jörg von Frantzius wrote:
>
>> Hi Craig,
>>
>> I was already afraid that "create a persistent instance" might only
>> apply to the PM cache, not the datastore (but only after second
>> read). However, would you say that JPOX is not JDO2 compliant if it
>> created missing instances in the datastore anyway? Will there be a
>> test in the TCK2 that expects an exception to be thrown if a detached
>> instances does not exist in the datastore?
>>
>> And, most of all, what sense would it make to forbid the creation of
>> missing detached instances in the datastore? There is lots of
>> application for that behaviour, and at least I don't know of any
>> problem with it.
>>
>> Regards,
>> Jörg
>>
>> Craig L Russell schrieb:
>>> Hi Jörg,
>>>
>>> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>>>
>>>> Craig L Russell schrieb:
>>>>>> Also I find it confusing that the method most prominently used
>>>>>> for inserting new objects shouldn't do so for detached instances.
>>>>>
>>>>> There is a bunch of history that you should look at, most of which
>>>>> is in the jdo-dev archives. Bottom line, we used to have a
>>>>> different API, attachCopy, but we looked at what it had to do for
>>>>> transient and detached instances and decided that it wasn't worth
>>>>> making a different API for attaching detached instances.
>>>> That particular behaviour of attachCopy() wasn't really specified,
>>>> but it was pleasant JPOX-specific behaviour, if I remember
>>>> correctly. I saw the discussion and I didn't see where inserting
>>>> the instances would be forbidden by the spec, and still I don't see
>>>> where it says that, especially in the light of 12.6.7. Please
>>>> excuse my ignorance, where does it say that?
>>>
>>> <spec>
>>> These methods make transient instances persistent and apply detached
>>> instance changes
>>> to the cache.
>>> ...
>>> For a detached instance, they locate or create a persistent
>>> instance with the same JDO identity as the detached instance, and
>>> merge the persistent
>>> state of the detached instance into the persistent instance. Only
>>> the state of persistent fields
>>> is merged.
>>> </spec>
>>>
>>> This means that if there is already a persistent instance in the
>>> cache with the same object id as the detached instance, the detached
>>> state will be merged. If there is not a persistent instance in the
>>> cache, a cache instance is created and the detached state is merged
>>> with the persistent instance.
>>>
>>> But there is no creation aspect of makePersistent on a detached
>>> instance.
>>>
>>> Craig
>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Craig
>>>>>
>>>>>>>
>>>>>>> Craig
>>>>>>>
>>>>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> What happens when we invoke makePersistent on a detached
>>>>>>>> instance that was
>>>>>>>> deleted by another isolated process? I suspect that we raise an
>>>>>>>> exception
>>>>>>>> instead of reinserting it for a second time. Is that right?
>>>>>>>>
>>>>>>>> Maybe this can be clarified in the spec.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>
>>>>>>> Craig Russell
>>>>>>> Architect, Sun Java Enterprise System
>>>>>>> http://java.sun.com/products/jdo
>>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Craig Russell
>>>>> Architect, Sun Java Enterprise System
>>>>> http://java.sun.com/products/jdo
>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: makePersistent detached instance deleted on database
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Jörg,
There are no tests planned for this behavior.
The issue is that it violates the contract of detachment. Detachment
is intended to provide a "long-running optimistic transaction" in
which conflicts are detected in a subsequent transaction.
If an instance is detached and then the underlying datastore instance
is deleted, this is a consistency violation that should be detected
by the transaction semantics. For example, in an order system, if a
customer is in a long-running transaction with "groovy beads" in the
shopping cart, and the administrators decide that "groovy beads" are
no longer to be sold, you want the order that contains "groovy beads"
to be rejected when the shopping cart arrives at checkout. You don't
want that order to reinsert "groovy beads" into the database.
Craig
On Mar 9, 2006, at 8:40 AM, Jörg von Frantzius wrote:
> Hi Craig,
>
> I was already afraid that "create a persistent instance" might only
> apply to the PM cache, not the datastore (but only after second
> read). However, would you say that JPOX is not JDO2 compliant if it
> created missing instances in the datastore anyway? Will there be a
> test in the TCK2 that expects an exception to be thrown if a
> detached instances does not exist in the datastore?
>
> And, most of all, what sense would it make to forbid the creation
> of missing detached instances in the datastore? There is lots of
> application for that behaviour, and at least I don't know of any
> problem with it.
>
> Regards,
> Jörg
>
> Craig L Russell schrieb:
>> Hi Jörg,
>>
>> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>>
>>> Craig L Russell schrieb:
>>>>> Also I find it confusing that the method most prominently used
>>>>> for inserting new objects shouldn't do so for detached instances.
>>>>
>>>> There is a bunch of history that you should look at, most of
>>>> which is in the jdo-dev archives. Bottom line, we used to have a
>>>> different API, attachCopy, but we looked at what it had to do
>>>> for transient and detached instances and decided that it wasn't
>>>> worth making a different API for attaching detached instances.
>>> That particular behaviour of attachCopy() wasn't really
>>> specified, but it was pleasant JPOX-specific behaviour, if I
>>> remember correctly. I saw the discussion and I didn't see where
>>> inserting the instances would be forbidden by the spec, and still
>>> I don't see where it says that, especially in the light of
>>> 12.6.7. Please excuse my ignorance, where does it say that?
>>
>> <spec>
>> These methods make transient instances persistent and apply
>> detached instance changes
>> to the cache.
>> ...
>> For a detached instance, they locate or create a persistent
>> instance with the same JDO identity as the detached instance, and
>> merge the persistent
>> state of the detached instance into the persistent instance. Only
>> the state of persistent fields
>> is merged.
>> </spec>
>>
>> This means that if there is already a persistent instance in the
>> cache with the same object id as the detached instance, the
>> detached state will be merged. If there is not a persistent
>> instance in the cache, a cache instance is created and the
>> detached state is merged with the persistent instance.
>>
>> But there is no creation aspect of makePersistent on a detached
>> instance.
>>
>> Craig
>>
>>>>
>>>> Regards,
>>>>
>>>> Craig
>>>>
>>>>>>
>>>>>> Craig
>>>>>>
>>>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> What happens when we invoke makePersistent on a detached
>>>>>>> instance that was
>>>>>>> deleted by another isolated process? I suspect that we raise
>>>>>>> an exception
>>>>>>> instead of reinserting it for a second time. Is that right?
>>>>>>>
>>>>>>> Maybe this can be clarified in the spec.
>>>>>>>
>>>>>>> Regards,
>>>>>>
>>>>>> Craig Russell
>>>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>>>> products/jdo
>>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>
>>>>>
>>>>>
>>>>
>>>> Craig Russell
>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>> products/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: makePersistent detached instance deleted on database
Posted by Jörg von Frantzius <jo...@artnology.com>.
Hi Craig,
I was already afraid that "create a persistent instance" might only
apply to the PM cache, not the datastore (but only after second read).
However, would you say that JPOX is not JDO2 compliant if it created
missing instances in the datastore anyway? Will there be a test in the
TCK2 that expects an exception to be thrown if a detached instances does
not exist in the datastore?
And, most of all, what sense would it make to forbid the creation of
missing detached instances in the datastore? There is lots of
application for that behaviour, and at least I don't know of any problem
with it.
Regards,
Jörg
Craig L Russell schrieb:
> Hi Jörg,
>
> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>
>> Craig L Russell schrieb:
>>>> Also I find it confusing that the method most prominently used for
>>>> inserting new objects shouldn't do so for detached instances.
>>>
>>> There is a bunch of history that you should look at, most of which
>>> is in the jdo-dev archives. Bottom line, we used to have a different
>>> API, attachCopy, but we looked at what it had to do for transient
>>> and detached instances and decided that it wasn't worth making a
>>> different API for attaching detached instances.
>> That particular behaviour of attachCopy() wasn't really specified,
>> but it was pleasant JPOX-specific behaviour, if I remember correctly.
>> I saw the discussion and I didn't see where inserting the instances
>> would be forbidden by the spec, and still I don't see where it says
>> that, especially in the light of 12.6.7. Please excuse my ignorance,
>> where does it say that?
>
> <spec>
> These methods make transient instances persistent and apply detached
> instance changes
> to the cache.
> ...
> For a detached instance, they locate or create a persistent
> instance with the same JDO identity as the detached instance, and
> merge the persistent
> state of the detached instance into the persistent instance. Only the
> state of persistent fields
> is merged.
> </spec>
>
> This means that if there is already a persistent instance in the cache
> with the same object id as the detached instance, the detached state
> will be merged. If there is not a persistent instance in the cache, a
> cache instance is created and the detached state is merged with the
> persistent instance.
>
> But there is no creation aspect of makePersistent on a detached instance.
>
> Craig
>
>>>
>>> Regards,
>>>
>>> Craig
>>>
>>>>>
>>>>> Craig
>>>>>
>>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> What happens when we invoke makePersistent on a detached instance
>>>>>> that was
>>>>>> deleted by another isolated process? I suspect that we raise an
>>>>>> exception
>>>>>> instead of reinserting it for a second time. Is that right?
>>>>>>
>>>>>> Maybe this can be clarified in the spec.
>>>>>>
>>>>>> Regards,
>>>>>
>>>>> Craig Russell
>>>>> Architect, Sun Java Enterprise System
>>>>> http://java.sun.com/products/jdo
>>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>>> P.S. A good JDO? O, Gasp!
>>>>>
>>>>
>>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: makePersistent detached instance deleted on database
Posted by Erik Bengtson <er...@jpox.org>.
JPOXers,
Please note that the current JPOX behaviour will change to align with JDO 2
spec.
Please track a discussion on vendor extension here
http://www.jpox.org/servlet/jira/browse/CORE-2741
Regards,
Quoting Craig L Russell <Cr...@Sun.COM>:
> Hi Jörg,
>
> On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
>
> > Craig L Russell schrieb:
> >>> Also I find it confusing that the method most prominently used
> >>> for inserting new objects shouldn't do so for detached instances.
> >>
> >> There is a bunch of history that you should look at, most of which
> >> is in the jdo-dev archives. Bottom line, we used to have a
> >> different API, attachCopy, but we looked at what it had to do for
> >> transient and detached instances and decided that it wasn't worth
> >> making a different API for attaching detached instances.
> > That particular behaviour of attachCopy() wasn't really specified,
> > but it was pleasant JPOX-specific behaviour, if I remember
> > correctly. I saw the discussion and I didn't see where inserting
> > the instances would be forbidden by the spec, and still I don't see
> > where it says that, especially in the light of 12.6.7. Please
> > excuse my ignorance, where does it say that?
>
> <spec>
> These methods make transient instances persistent and apply detached
> instance changes
> to the cache.
> ...
> For a detached instance, they locate or create a persistent
> instance with the same JDO identity as the detached instance, and
> merge the persistent
> state of the detached instance into the persistent instance. Only the
> state of persistent fields
> is merged.
> </spec>
>
> This means that if there is already a persistent instance in the
> cache with the same object id as the detached instance, the detached
> state will be merged. If there is not a persistent instance in the
> cache, a cache instance is created and the detached state is merged
> with the persistent instance.
>
> But there is no creation aspect of makePersistent on a detached
> instance.
>
> Craig
>
> >>
> >> Regards,
> >>
> >> Craig
> >>
> >>>>
> >>>> Craig
> >>>>
> >>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> What happens when we invoke makePersistent on a detached
> >>>>> instance that was
> >>>>> deleted by another isolated process? I suspect that we raise an
> >>>>> exception
> >>>>> instead of reinserting it for a second time. Is that right?
> >>>>>
> >>>>> Maybe this can be clarified in the spec.
> >>>>>
> >>>>> Regards,
> >>>>
> >>>> Craig Russell
> >>>> Architect, Sun Java Enterprise System http://java.sun.com/
> >>>> products/jdo
> >>>> 408 276-5638 mailto:Craig.Russell@sun.com
> >>>> P.S. A good JDO? O, Gasp!
> >>>>
> >>>
> >>>
> >>
> >> Craig Russell
> >> Architect, Sun Java Enterprise System http://java.sun.com/products/
> >> jdo
> >> 408 276-5638 mailto:Craig.Russell@sun.com
> >> P.S. A good JDO? O, Gasp!
> >>
> >
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Re: makePersistent detached instance deleted on database
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Jörg,
On Mar 9, 2006, at 1:43 AM, Jörg von Frantzius wrote:
> Craig L Russell schrieb:
>>> Also I find it confusing that the method most prominently used
>>> for inserting new objects shouldn't do so for detached instances.
>>
>> There is a bunch of history that you should look at, most of which
>> is in the jdo-dev archives. Bottom line, we used to have a
>> different API, attachCopy, but we looked at what it had to do for
>> transient and detached instances and decided that it wasn't worth
>> making a different API for attaching detached instances.
> That particular behaviour of attachCopy() wasn't really specified,
> but it was pleasant JPOX-specific behaviour, if I remember
> correctly. I saw the discussion and I didn't see where inserting
> the instances would be forbidden by the spec, and still I don't see
> where it says that, especially in the light of 12.6.7. Please
> excuse my ignorance, where does it say that?
<spec>
These methods make transient instances persistent and apply detached
instance changes
to the cache.
...
For a detached instance, they locate or create a persistent
instance with the same JDO identity as the detached instance, and
merge the persistent
state of the detached instance into the persistent instance. Only the
state of persistent fields
is merged.
</spec>
This means that if there is already a persistent instance in the
cache with the same object id as the detached instance, the detached
state will be merged. If there is not a persistent instance in the
cache, a cache instance is created and the detached state is merged
with the persistent instance.
But there is no creation aspect of makePersistent on a detached
instance.
Craig
>>
>> Regards,
>>
>> Craig
>>
>>>>
>>>> Craig
>>>>
>>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> What happens when we invoke makePersistent on a detached
>>>>> instance that was
>>>>> deleted by another isolated process? I suspect that we raise an
>>>>> exception
>>>>> instead of reinserting it for a second time. Is that right?
>>>>>
>>>>> Maybe this can be clarified in the spec.
>>>>>
>>>>> Regards,
>>>>
>>>> Craig Russell
>>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>>> products/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: makePersistent detached instance deleted on database
Posted by Jörg von Frantzius <jo...@artnology.com>.
Craig L Russell schrieb:
>> Also I find it confusing that the method most prominently used for
>> inserting new objects shouldn't do so for detached instances.
>
> There is a bunch of history that you should look at, most of which is
> in the jdo-dev archives. Bottom line, we used to have a different API,
> attachCopy, but we looked at what it had to do for transient and
> detached instances and decided that it wasn't worth making a different
> API for attaching detached instances.
That particular behaviour of attachCopy() wasn't really specified, but
it was pleasant JPOX-specific behaviour, if I remember correctly. I saw
the discussion and I didn't see where inserting the instances would be
forbidden by the spec, and still I don't see where it says that,
especially in the light of 12.6.7. Please excuse my ignorance, where
does it say that?
>
> Regards,
>
> Craig
>
>>>
>>> Craig
>>>
>>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>> What happens when we invoke makePersistent on a detached instance
>>>> that was
>>>> deleted by another isolated process? I suspect that we raise an
>>>> exception
>>>> instead of reinserting it for a second time. Is that right?
>>>>
>>>> Maybe this can be clarified in the spec.
>>>>
>>>> Regards,
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: makePersistent detached instance deleted on database
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Joerg,
On Mar 8, 2006, at 6:10 PM, Joerg von Frantzius wrote:
> Craig L Russell schrieb:
>> Hi Erik,
>>
>> When you invoke makePersistent on a detached instance, the
>> instance must exist in the database. You don't insert it at commit.
>> [..]
> Does that mean that makePersistent() must not insert detached
> instances for which it cannot find an object in the datastore?
Yes.
> In 12.6.7 it has "For a detached instance, they [the methods
> makePersistent() and makePersistentAll()] locate /or create a
> persistent instance/ with the same JDO identity as the detached
> instance, and merge the persistent state of the detached instance
> into the persistent instance."
>
> I'm asking because our replication algorithm relies on that.
Good.
> Also I find it confusing that the method most prominently used for
> inserting new objects shouldn't do so for detached instances.
There is a bunch of history that you should look at, most of which is
in the jdo-dev archives. Bottom line, we used to have a different
API, attachCopy, but we looked at what it had to do for transient and
detached instances and decided that it wasn't worth making a
different API for attaching detached instances.
Regards,
Craig
>>
>> Craig
>>
>> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>>
>>>
>>>
>>> Hi,
>>>
>>> What happens when we invoke makePersistent on a detached instance
>>> that was
>>> deleted by another isolated process? I suspect that we raise an
>>> exception
>>> instead of reinserting it for a second time. Is that right?
>>>
>>> Maybe this can be clarified in the spec.
>>>
>>> Regards,
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: makePersistent detached instance deleted on database
Posted by Joerg von Frantzius <jo...@artnology.com>.
Craig L Russell schrieb:
> Hi Erik,
>
> When you invoke makePersistent on a detached instance, the instance
> must exist in the database. You don't insert it at commit.[..]
Does that mean that makePersistent() must not insert detached instances
for which it cannot find an object in the datastore?
In 12.6.7 it has "For a detached instance, they [the methods
makePersistent() and makePersistentAll()] locate /or create a persistent
instance/ with the same JDO identity as the detached instance, and merge
the persistent state of the detached instance into the persistent
instance."
I'm asking because our replication algorithm relies on that. Also I find
it confusing that the method most prominently used for inserting new
objects shouldn't do so for detached instances.
>
> Craig
>
> On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>
>>
>>
>> Hi,
>>
>> What happens when we invoke makePersistent on a detached instance
>> that was
>> deleted by another isolated process? I suspect that we raise an
>> exception
>> instead of reinserting it for a second time. Is that right?
>>
>> Maybe this can be clarified in the spec.
>>
>> Regards,
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: makePersistent detached instance deleted on database
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Erik,
When you invoke makePersistent on a detached instance, the instance
must exist in the database. You don't insert it at commit. This is
similar to retrieving an instance in one transaction and having a
parallel transaction delete it.
Craig
On Mar 8, 2006, at 7:14 AM, Erik Bengtson wrote:
>
>
> Hi,
>
> What happens when we invoke makePersistent on a detached instance
> that was
> deleted by another isolated process? I suspect that we raise an
> exception
> instead of reinserting it for a second time. Is that right?
>
> Maybe this can be clarified in the spec.
>
> Regards,
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: makePersistent detached instance deleted on database
Posted by Marco Schulze <Ma...@NightLabs.de>.
Marco Schulze wrote:
> Hello JDO team,
>
> we have the following situation, which IMHO Erik is refering to:
>
> We have multiple datastores where each datastore belongs to one
> organisation (e.g. company). In order for the organisations to do
> business with each other, they need to exchange data. Thus, all our
> JDO objects are owned by one datastore and have the organisationID of
> this datastore as part of their composite PK (we are using exclusively
> application identity).
>
> Now, say organisation B wants to become a reseller for organisation A
> concerning their ProductType Mercedes320E. This causes the object
> graph of the Mercedes320E (including price configuration and a lot of
> other data) to be copied from datastore A to datastore B. Of course,
> some of the objects within this graph (e.g. the currency EUR) already
> exist in datastore B and some don't (e.g. the currency $). The ones
> that don't exist yet must be added - the ones that are already there
> need an update.
>
> After this initial copy, the copied object will be updated whenever
> the object graph is modified in the original datastore. Until now, as
> well for the initial copying as for the updates, I simply detached my
> ProductType from datastore A with all the necessary fetch-groups and
> attached it in datastore B. This was simply adding/overwriting all the
> data within the object graph and that's basically the behaviour I need.
>
> I hope I could explain the situation well enough.
>
> Best regards,
>
> Marco Schulze
> NightLabs GmbH
I just wanted to clarify sth.: Of course every organisation is at the
same time publisher of objects (e.g. manufacturer of a product) and
subscriber (e.g. reseller). Thus, it is not a master-slave-scenario, but
all organisations need to be able to copy data from another organisation
defining using certain fetch-groups.
Re: makePersistent detached instance deleted on database
Posted by Marco Schulze <Ma...@NightLabs.de>.
Erik Bengtson wrote:
>Hi,
>
>What happens when we invoke makePersistent on a detached instance that was
>deleted by another isolated process? I suspect that we raise an exception
>instead of reinserting it for a second time. Is that right?
>
>Maybe this can be clarified in the spec.
>
>Regards,
Hello JDO team,
we have the following situation, which IMHO Erik is refering to:
We have multiple datastores where each datastore belongs to one
organisation (e.g. company). In order for the organisations to do
business with each other, they need to exchange data. Thus, all our JDO
objects are owned by one datastore and have the organisationID of this
datastore as part of their composite PK (we are using exclusively
application identity).
Now, say organisation B wants to become a reseller for organisation A
concerning their ProductType Mercedes320E. This causes the object graph
of the Mercedes320E (including price configuration and a lot of other
data) to be copied from datastore A to datastore B. Of course, some of
the objects within this graph (e.g. the currency EUR) already exist in
datastore B and some don't (e.g. the currency $). The ones that don't
exist yet must be added - the ones that are already there need an update.
After this initial copy, the copied object will be updated whenever the
object graph is modified in the original datastore. Until now, as well
for the initial copying as for the updates, I simply detached my
ProductType from datastore A with all the necessary fetch-groups and
attached it in datastore B. This was simply adding/overwriting all the
data within the object graph and that's basically the behaviour I need.
I hope I could explain the situation well enough.
Best regards,
Marco Schulze
NightLabs GmbH
--
______________________________________________
Need a free ERP system? Use http://jfire.org
______________________________________________
Marco Schulze NightLabs GmbH
Rehlingstr. 6d
79100 Freiburg
Germany
eMail: Marco@NightLabs.de
Fon: +49-761-2 111 793
Mobile: +49-172-212 63 80
Fax: +49-761-2 111 798
WWW: http://www.NightLabs.de
Geschäftsführung:
Marco Schulze <Ma...@NightLabs.de>
Niklas Schiffler <Ni...@NightLabs.de>
Eintragung:
Amtsgericht Freiburg, HRB 6186
______________________________________________