Re: 2.1 Spec: detached-dirty parameters to makePersistent() when DetachAllOnCommit=true

[Craig L Russell]

So if we introduce a flag that uses the same instance on attach, we might want to have the flag called CopyOnMakePersistent and have true be the current specified behavior and false be the new behavior we've been discussing.

Craig

On Aug 7, 2007, at 12:11 PM, Andy Jefferson wrote:

The defaults for these kinds of options have never been specified (even Optimistic).

With this restriction in place, however, would I be able to do the
following?

// fetch a detched object
Query q = pm.newQuery(Foo.class);
q.setUnique(true);
Foo foo = (Foo) q.execute();

tx.commit() around it then its definitely fine. Nothing in the spec

non-tx read will do the detach.

"detachAllOnCommit" will transition instances to detached *at commit*. You have no commit here (using nontransactionalRead ?). If you have tx.begin(), definition of "detachAllOnCommit" implies (to me) that queries run with

// make it dirty:
foo.setBar("bar");

"foo" : detached-clean -> detached-dirty

// attach
pm.currentTransaction().begin();
pm.makePersistent(foo);

"foo" : detached-dirty -> persistent-clean

pm.currentTransaction().commit();

"foo" : persistent-clean -> detached-clean

// dirty it once more
foo.addBaz("baz");

"foo" : detached-clean -> detached-dirty

// and attach it a second time

"foo" : detached-dirty -> persistence-clean

- wouldn't this cause the  JDOUserException you mention above?

to the same PM as one that already had it.




--
Andy  (Java Persistent Objects - http://www.jpox.org)

No. If referring to the same PM, the object would have been removed from L1 cache at detach. The exception I was referring to was if you did a separate PM.detachCopy() or detached it from a different PM and *then* tried to attach

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature