db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg von Frantzius <joerg.von.frantz...@artnology.com>
Subject Re: makePersistent detached instance deleted on database
Date Fri, 10 Mar 2006 16:30:49 GMT
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!
>>>
>>>       
>>     
>
>
>
>
>   


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message