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? >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> 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! >> >