On Jan 20, 2006, at 7:29 AM, Michael Watzek wrote:
Hi Craig,
I have some questions wrt lifecycle transitions. Please see below:
1) Does pm.detachCopy(persistent-nontransactional-dirty) throw an exception?
Yes.
2) How does a non-transactional-dirty instance transition at commit time when DetachAllOnCommit is true?
By the time the transaction completes, it's been flushed and so it transitions to detached-clean.
3) Does pm.makeTransient(persistent-nontransactional-dirty) throw an exception?
Good question. It's not specifically mentioned, and I don't think it should be allowed. It should throw a JDOUserException.
4) At commit time a non-transactional-dirty instance transitions to hollow when DetachAllOnCommit is false and RestoreValues is false. As a consequence, the changes made before begin are lost. Is this intentional?
When DetachAllOnCommit is true, it overrides the RetainValues setting; the state transition is to detached and the fields are loaded according to the FetchPlan. This is not now but needs to be explicit in the specification. AI Craig.
5) At commit time flushing a non-transactional-dirty instance may result in a concurrency conflict for optimistic transactions because the spec requires a version check. For datastore transactions commit would be successful. Non-transactional-dirty seems to be the only state where both transaction types have different semantics wrt concurrency conflicts. Is this intentional?
Yes.
smime.p7s