You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Michael Watzek <mw...@spree.de> on 2006/01/20 16:29:50 UTC
Questions wrt lifecycle transitions
Hi Craig,
I have some questions wrt lifecycle transitions. Please see below:
1) Does pm.detachCopy(persistent-nontransactional-dirty) throw an exception?
2) How does a non-transactional-dirty instance transition at commit time
when DetachAllOnCommit is true?
3) Does pm.makeTransient(persistent-nontransactional-dirty) throw an
exception?
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?
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 concurreny
conflicts. Is this intentional?
Regards,
Michael
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
Re: Questions wrt lifecycle transitions
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Michael,
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.
Craig
>
> Regards,
> Michael
> --
> -------------------------------------------------------------------
> Michael Watzek Tech@Spree Engineering GmbH
> mailto:mwa.tech@spree.de Buelowstr. 66
> Tel.: ++49/30/235 520 36 10783 Berlin - Germany
> Fax.: ++49/30/217 520 12 http://www.spree.de/
> -------------------------------------------------------------------
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!