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 Thu, 09 Mar 2006 17:48:20 GMT
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!
>


Mime
View raw message