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

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();

"detachAllOnCommit" will transition instances to detached *at commit*. You have no commit here (using nontransactionalRead ?). If you have tx.begin(),
tx.commit() around it then its definitely fine. Nothing in the spec
definition of "detachAllOnCommit" implies (to me) that queries run with
non-tx read will do the detach.

Sorry - my bad. I meant to wrap the above in a transaction, thus detaching the enlisted foo instance.


// 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 -> persistent-clean

I'm with you until this last one... It would transition from persistent-clean to detached-clean upon committing the transaction, right? If so, then we're aligned...


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

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
to the same PM as one that already had it.

Aha.. not knowing how the L1 cache really works, I didn't know that instances get evicted on detach. This would work, it seems. More to the point, my application uses a new PM for each successive makePersist() call, so there's even less chance of the instance already existing in the L1 cache.

Sounds like we're on the right track...

- Chris


Reply via email to