db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: makePersistent detached instance deleted on database
Date Thu, 09 Mar 2006 18:03:37 GMT
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
View raw message