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 2005/12/08 13:52:40 UTC
Proposal for non-covered assertions in chapter 5.6.2
Hi Craig,
please find the proposal for non-covered assertions in chapter 5.6.2
(Persistent-nontransactional-dirty) below. The proposal is based on spec
version 9/12/2005.
Regards,
Michael
Proposal:
- Rename assertions A5.6.1-1 and A5.6.1-2 in this chapter to A5.6.2-1
and A5.6.2-2
- A5.6.2-3 [At some future point, the application can begin a
transaction and incorporate the changes into the transactional
state. Committing the transaction makes the changes made outside the
transaction durable.]
- A5.6.2-4 [A persistent-nontransactional-dirty instance transitions to
hollow if it is the parameter of evict or evictAll. This allows the
application to remove instances from the set of instances whose state
is to be committed to the datastore.]
- A5.6.2-5 [If a datastore transaction is begun, commit will write the
changes to the datastore with no checking as to the current state of the
instances in the datastore. That is, the changes made outside the
transaction together with any changes made inside the transaction will
overwrite the current state of the datastore. The
persistent-nontransactional-dirty instances will transition according to
the RetainValues flag. With the RetainValues flag set to true,
persistent-nontransactional-dirty instances will transition to
persistent-nontransactional. With the RetainValues flag set to false,
persistent-nontransactional-dirty instances will transition to hollow.]
- A5.6.2-6 [If a datastore transaction is begun, rollback will not write
any changes to the datastore. The persistent-nontransactional-dirty
instances will transition according to the RestoreValues flag.
With the RestoreValues flag set to true,
persistent-nontransactional-dirty instances will make no state
transition, but the fields will be restored to their values as of the
beginning of the transaction, and any changes made within the
transaction will be discarded. With the RestoreValues flag set to false,
persistent-nontransactional-dirty instances will transition to hollow.]
- A5.6.2-7 [If an optimistic transaction is begun, commit will write the
changes to the datastore after checking as to the current state of the
instances in the datastore. The changes made outside the transaction
together with any changes made inside the transaction will update the
current state of the datastore if the version checking is successful.
The persistent-nontransactional-dirty instances will transition
according to the RetainValues flag. With the RetainValues flag set to
true, persistentnontransactional-dirty instances will transition to
persistent-nontransactional. With the Retain-Values flag set to false,
persistent-nontransactional-dirty instances will transition to hollow.]
- A5.6.2-8 [If an optimistic transaction is begun, rollback will not
write any changes to the datastore. The
persistent-nontransactional-dirty instances will transition according to
the RestoreValues flag. With the RestoreValues flag set to true,
persistent-nontransactional-dirty instances will make no state
transition, but the fields will be restored to their values as of the
beginning of the transaction, and any changes made within the
transaction will be discarded. With the RestoreValues flag set to false,
persistent-nontransactional-dirty instances will transition to hollow.]
--
-------------------------------------------------------------------
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: Proposal for non-covered assertions in chapter 5.6.2
Posted by Michelle Caisse <Mi...@Sun.COM>.
Doh! I was missing something. You deleted one and renumbered the
others. -- Michelle
Michelle Caisse wrote:
> Hi Craig,
>
> Am I missing something or was there maybe a cut and paste error from
> the spec? I don't see Michael's A5.6.2-8 in your spec text.
>
> -- Michelle
>
> Craig L Russell wrote:
>
>> Hi Michael,
>>
>> Thanks. I've updated the spec with new assertion numbers.
>>
>> JDO instances that represent specific persistent data in the
>> datastore, whose values may be currently loaded but not
>> transactionally consistent, and have been modified since the last
>> commit, are persistent-nontransactional-dirty. A5.6.2-1 [ There is a
>> JDO Identity associated with these instances], and A5.6.2-2 [
>> transactional instances can be obtained from the object ids.]
>> The persistent-nontransactional-dirty state allows applications to
>> operate on nontransactional instances in the cache and make changes
>> to the instances without having a transaction active. At some future
>> point, the application can begin a transaction and incorporate the
>> changes into the transactional state. Committing the transaction
>> makes the changes made outside the transaction durable.
>> A5.6.2-3 [ A persistent-nontransactional-dirty instance transitions
>> to hollow if it is the parameter of evict or evictAll. This allows
>> the application to remove instances from the set of instances whose
>> state is to be committed to the datastore.]
>> A5.6.2-4 [ If a datastore transaction is begun, commit will write the
>> changes to the datastore with no checking as to the current state of
>> the instances in the datastore. That is, the changes made outside the
>> transaction together with any changes made inside the transaction
>> will overwrite the current state of the datastore. The
>> persistent-nontransactional-dirty instances will transition according
>> to the RetainValues flag. With the RetainValues flag set to true,
>> persistent-nontransactional-dirty instances will transition to
>> persistent-nontransactional. With the RetainValues flag set to false,
>> persistent-nontransactional-dirty instances will transition to hollow. ]
>> A5.6.2-5 [ If a datastore transaction is begun, rollback will not
>> write any changes to the datastore. The
>> persistent-nontransactional-dirty instances will transition according
>> to the RestoreValues flag. With the RestoreValues flag set to true,
>> persistent-nontransactional-dirty instances will make no state
>> transition, but the fields will be restored to their values as of the
>> beginning of the transaction, and any changes made within the
>> transaction will be discarded. With the RestoreValues flag set to
>> false, persistent-nontransactional-dirty instances will transition to
>> hollow.]
>> A5.6.2-6 [ If an optimistic transaction is begun, commit will write
>> the changes to the datastore after checking as to the current state
>> of the instances in the datastore. The changes made outside the
>> transaction together with any changes made inside the transaction
>> will update the current state of the datastore if the version
>> checking is successful. The persistent-nontransactional-dirty
>> instances will transition according to the RetainValues flag. With
>> the RetainValues flag set to true, persistent-nontransactional-dirty
>> instances will transition to persistent-nontransactional. With the
>> RetainValues flag set to false, persistent-nontransactional-dirty
>> instances will transition to hollow. ]
>> A5.6.2-7 [ If an optimistic transaction is begun, rollback will not
>> write any changes to the datastore. The
>> persistent-nontransactional-dirty instances will transition according
>> to the RestoreValues flag. With the RestoreValues flag set to true,
>> persistent-nontransactional-dirty instances will make no state
>> transition, but the fields will be restored to their values as of the
>> beginning of the transaction, and any changes made within the
>> transaction will be discarded. With the RestoreValues flag set to
>> false, persistent-nontransactional-dirty instances will transition to
>> hollow.]
>> see below for comments.
>>
>> On Dec 8, 2005, at 4:52 AM, Michael Watzek wrote:
>>
>>> Hi Craig,
>>>
>>> please find the proposal for non-covered assertions in chapter 5.6.2
>>> (Persistent-nontransactional-dirty) below. The proposal is based on
>>> spec version 9/12/2005.
>>>
>>> Regards,
>>> Michael
>>>
>>> Proposal:
>>>
>>> - Rename assertions A5.6.1-1 and A5.6.1-2 in this chapter to
>>> A5.6.2-1 and A5.6.2-2
>>>
>>> - A5.6.2-3 [At some future point, the application can begin a
>>> transaction and incorporate the changes into the transactional
>>> state. Committing the transaction makes the changes made outside the
>>> transaction durable.]
>>
>>
>>
>> This assertion will be tested by the following assertions.
>> Craig
>>
>>>
>>> - A5.6.2-4 [A persistent-nontransactional-dirty instance transitions
>>> to hollow if it is the parameter of evict or evictAll. This allows
>>> the application to remove instances from the set of instances whose
>>> state
>>> is to be committed to the datastore.]
>>>
>>> - A5.6.2-5 [If a datastore transaction is begun, commit will write
>>> the changes to the datastore with no checking as to the current
>>> state of the instances in the datastore. That is, the changes made
>>> outside the transaction together with any changes made inside the
>>> transaction will overwrite the current state of the datastore. The
>>> persistent-nontransactional-dirty instances will transition
>>> according to the RetainValues flag. With the RetainValues flag set
>>> to true, persistent-nontransactional-dirty instances will transition
>>> to persistent-nontransactional. With the RetainValues flag set to
>>> false, persistent-nontransactional-dirty instances will transition
>>> to hollow.]
>>>
>>> - A5.6.2-6 [If a datastore transaction is begun, rollback will not
>>> write any changes to the datastore. The
>>> persistent-nontransactional-dirty instances will transition
>>> according to the RestoreValues flag.
>>> With the RestoreValues flag set to true,
>>> persistent-nontransactional-dirty instances will make no state
>>> transition, but the fields will be restored to their values as of
>>> the beginning of the transaction, and any changes made within the
>>> transaction will be discarded. With the RestoreValues flag set to
>>> false, persistent-nontransactional-dirty instances will transition
>>> to hollow.]
>>>
>>> - A5.6.2-7 [If an optimistic transaction is begun, commit will write
>>> the changes to the datastore after checking as to the current state
>>> of the instances in the datastore. The changes made outside the
>>> transaction
>>> together with any changes made inside the transaction will update
>>> the current state of the datastore if the version checking is
>>> successful. The persistent-nontransactional-dirty instances will
>>> transition
>>> according to the RetainValues flag. With the RetainValues flag set
>>> to true, persistentnontransactional-dirty instances will transition
>>> to persistent-nontransactional. With the Retain-Values flag set to
>>> false, persistent-nontransactional-dirty instances will transition
>>> to hollow.]
>>>
>>> - A5.6.2-8 [If an optimistic transaction is begun, rollback will not
>>> write any changes to the datastore. The
>>> persistent-nontransactional-dirty instances will transition
>>> according to the RestoreValues flag. With the RestoreValues flag set
>>> to true, persistent-nontransactional-dirty instances will make no
>>> state transition, but the fields will be restored to their values as
>>> of the beginning of the transaction, and any changes made within the
>>> transaction will be discarded. With the RestoreValues flag set to
>>> false, persistent-nontransactional-dirty instances will transition
>>> to hollow.]
>>>
>>> --
>>> -------------------------------------------------------------------
>>> 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!
>>
>
>
Re: Proposal for non-covered assertions in chapter 5.6.2
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Michelle,
I removed A5.6.2-3 because it was redundant, and renamed all of the
following assertions.
Craig
On Dec 8, 2005, at 8:42 PM, Michelle Caisse wrote:
> Hi Craig,
>
> Am I missing something or was there maybe a cut and paste error
> from the spec? I don't see Michael's A5.6.2-8 in your spec text.
>
> -- Michelle
>
> Craig L Russell wrote:
>
>> Hi Michael,
>>
>> Thanks. I've updated the spec with new assertion numbers.
>>
>> JDO instances that represent specific persistent data in the
>> datastore, whose values may be currently loaded but not
>> transactionally consistent, and have been modified since the last
>> commit, are persistent-nontransactional-dirty. A5.6.2-1 [ There is
>> a JDO Identity associated with these instances], and A5.6.2-2
>> [ transactional instances can be obtained from the object ids.]
>> The persistent-nontransactional-dirty state allows applications to
>> operate on nontransactional instances in the cache and make
>> changes to the instances without having a transaction active. At
>> some future point, the application can begin a transaction and
>> incorporate the changes into the transactional state. Committing
>> the transaction makes the changes made outside the transaction
>> durable.
>> A5.6.2-3 [ A persistent-nontransactional-dirty instance
>> transitions to hollow if it is the parameter of evict or evictAll.
>> This allows the application to remove instances from the set of
>> instances whose state is to be committed to the datastore.]
>> A5.6.2-4 [ If a datastore transaction is begun, commit will write
>> the changes to the datastore with no checking as to the current
>> state of the instances in the datastore. That is, the changes made
>> outside the transaction together with any changes made inside the
>> transaction will overwrite the current state of the datastore. The
>> persistent-nontransactional-dirty instances will transition
>> according to the RetainValues flag. With the RetainValues flag set
>> to true, persistent-nontransactional-dirty instances will
>> transition to persistent-nontransactional. With the RetainValues
>> flag set to false, persistent-nontransactional-dirty instances
>> will transition to hollow. ]
>> A5.6.2-5 [ If a datastore transaction is begun, rollback will not
>> write any changes to the datastore. The persistent-
>> nontransactional-dirty instances will transition according to the
>> RestoreValues flag. With the RestoreValues flag set to true,
>> persistent-nontransactional-dirty instances will make no state
>> transition, but the fields will be restored to their values as of
>> the beginning of the transaction, and any changes made within the
>> transaction will be discarded. With the RestoreValues flag set to
>> false, persistent-nontransactional-dirty instances will transition
>> to hollow.]
>> A5.6.2-6 [ If an optimistic transaction is begun, commit will
>> write the changes to the datastore after checking as to the
>> current state of the instances in the datastore. The changes made
>> outside the transaction together with any changes made inside the
>> transaction will update the current state of the datastore if the
>> version checking is successful. The persistent-nontransactional-
>> dirty instances will transition according to the RetainValues
>> flag. With the RetainValues flag set to true, persistent-
>> nontransactional-dirty instances will transition to persistent-
>> nontransactional. With the RetainValues flag set to false,
>> persistent-nontransactional-dirty instances will transition to
>> hollow. ]
>> A5.6.2-7 [ If an optimistic transaction is begun, rollback will
>> not write any changes to the datastore. The persistent-
>> nontransactional-dirty instances will transition according to the
>> RestoreValues flag. With the RestoreValues flag set to true,
>> persistent-nontransactional-dirty instances will make no state
>> transition, but the fields will be restored to their values as of
>> the beginning of the transaction, and any changes made within the
>> transaction will be discarded. With the RestoreValues flag set to
>> false, persistent-nontransactional-dirty instances will transition
>> to hollow.]
>> see below for comments.
>>
>> On Dec 8, 2005, at 4:52 AM, Michael Watzek wrote:
>>
>>> Hi Craig,
>>>
>>> please find the proposal for non-covered assertions in chapter
>>> 5.6.2 (Persistent-nontransactional-dirty) below. The proposal is
>>> based on spec version 9/12/2005.
>>>
>>> Regards,
>>> Michael
>>>
>>> Proposal:
>>>
>>> - Rename assertions A5.6.1-1 and A5.6.1-2 in this chapter to
>>> A5.6.2-1 and A5.6.2-2
>>>
>>> - A5.6.2-3 [At some future point, the application can begin a
>>> transaction and incorporate the changes into the transactional
>>> state. Committing the transaction makes the changes made outside
>>> the transaction durable.]
>>
>>
>> This assertion will be tested by the following assertions.
>> Craig
>>
>>>
>>> - A5.6.2-4 [A persistent-nontransactional-dirty instance
>>> transitions to hollow if it is the parameter of evict or
>>> evictAll. This allows the application to remove instances from
>>> the set of instances whose state
>>> is to be committed to the datastore.]
>>>
>>> - A5.6.2-5 [If a datastore transaction is begun, commit will
>>> write the changes to the datastore with no checking as to the
>>> current state of the instances in the datastore. That is, the
>>> changes made outside the transaction together with any changes
>>> made inside the transaction will overwrite the current state of
>>> the datastore. The persistent-nontransactional-dirty instances
>>> will transition according to the RetainValues flag. With the
>>> RetainValues flag set to true, persistent-nontransactional-dirty
>>> instances will transition to persistent-nontransactional. With
>>> the RetainValues flag set to false, persistent-nontransactional-
>>> dirty instances will transition to hollow.]
>>>
>>> - A5.6.2-6 [If a datastore transaction is begun, rollback will
>>> not write any changes to the datastore. The persistent-
>>> nontransactional-dirty instances will transition according to the
>>> RestoreValues flag.
>>> With the RestoreValues flag set to true, persistent-
>>> nontransactional-dirty instances will make no state transition,
>>> but the fields will be restored to their values as of the
>>> beginning of the transaction, and any changes made within the
>>> transaction will be discarded. With the RestoreValues flag set to
>>> false, persistent-nontransactional-dirty instances will
>>> transition to hollow.]
>>>
>>> - A5.6.2-7 [If an optimistic transaction is begun, commit will
>>> write the changes to the datastore after checking as to the
>>> current state of the instances in the datastore. The changes made
>>> outside the transaction
>>> together with any changes made inside the transaction will update
>>> the current state of the datastore if the version checking is
>>> successful. The persistent-nontransactional-dirty instances will
>>> transition
>>> according to the RetainValues flag. With the RetainValues flag
>>> set to true, persistentnontransactional-dirty instances will
>>> transition to persistent-nontransactional. With the Retain-Values
>>> flag set to false, persistent-nontransactional-dirty instances
>>> will transition to hollow.]
>>>
>>> - A5.6.2-8 [If an optimistic transaction is begun, rollback will
>>> not write any changes to the datastore. The persistent-
>>> nontransactional-dirty instances will transition according to the
>>> RestoreValues flag. With the RestoreValues flag set to true,
>>> persistent-nontransactional-dirty instances will make no state
>>> transition, but the fields will be restored to their values as of
>>> the beginning of the transaction, and any changes made within the
>>> transaction will be discarded. With the RestoreValues flag set to
>>> false, persistent-nontransactional-dirty instances will
>>> transition to hollow.]
>>>
>>> --
>>> -------------------------------------------------------------------
>>> 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!
>>
>
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!
Re: Proposal for non-covered assertions in chapter 5.6.2
Posted by Michelle Caisse <Mi...@Sun.COM>.
Hi Craig,
Am I missing something or was there maybe a cut and paste error from the
spec? I don't see Michael's A5.6.2-8 in your spec text.
-- Michelle
Craig L Russell wrote:
> Hi Michael,
>
> Thanks. I've updated the spec with new assertion numbers.
>
> JDO instances that represent specific persistent data in the
> datastore, whose values may be currently loaded but not
> transactionally consistent, and have been modified since the last
> commit, are persistent-nontransactional-dirty. A5.6.2-1 [ There is a
> JDO Identity associated with these instances], and A5.6.2-2 [
> transactional instances can be obtained from the object ids.]
> The persistent-nontransactional-dirty state allows applications to
> operate on nontransactional instances in the cache and make changes to
> the instances without having a transaction active. At some future
> point, the application can begin a transaction and incorporate the
> changes into the transactional state. Committing the transaction makes
> the changes made outside the transaction durable.
> A5.6.2-3 [ A persistent-nontransactional-dirty instance transitions to
> hollow if it is the parameter of evict or evictAll. This allows the
> application to remove instances from the set of instances whose state
> is to be committed to the datastore.]
> A5.6.2-4 [ If a datastore transaction is begun, commit will write the
> changes to the datastore with no checking as to the current state of
> the instances in the datastore. That is, the changes made outside the
> transaction together with any changes made inside the transaction will
> overwrite the current state of the datastore. The
> persistent-nontransactional-dirty instances will transition according
> to the RetainValues flag. With the RetainValues flag set to true,
> persistent-nontransactional-dirty instances will transition to
> persistent-nontransactional. With the RetainValues flag set to false,
> persistent-nontransactional-dirty instances will transition to hollow. ]
> A5.6.2-5 [ If a datastore transaction is begun, rollback will not
> write any changes to the datastore. The
> persistent-nontransactional-dirty instances will transition according
> to the RestoreValues flag. With the RestoreValues flag set to true,
> persistent-nontransactional-dirty instances will make no state
> transition, but the fields will be restored to their values as of the
> beginning of the transaction, and any changes made within the
> transaction will be discarded. With the RestoreValues flag set to
> false, persistent-nontransactional-dirty instances will transition to
> hollow.]
> A5.6.2-6 [ If an optimistic transaction is begun, commit will write
> the changes to the datastore after checking as to the current state of
> the instances in the datastore. The changes made outside the
> transaction together with any changes made inside the transaction will
> update the current state of the datastore if the version checking is
> successful. The persistent-nontransactional-dirty instances will
> transition according to the RetainValues flag. With the RetainValues
> flag set to true, persistent-nontransactional-dirty instances will
> transition to persistent-nontransactional. With the RetainValues flag
> set to false, persistent-nontransactional-dirty instances will
> transition to hollow. ]
> A5.6.2-7 [ If an optimistic transaction is begun, rollback will not
> write any changes to the datastore. The
> persistent-nontransactional-dirty instances will transition according
> to the RestoreValues flag. With the RestoreValues flag set to true,
> persistent-nontransactional-dirty instances will make no state
> transition, but the fields will be restored to their values as of the
> beginning of the transaction, and any changes made within the
> transaction will be discarded. With the RestoreValues flag set to
> false, persistent-nontransactional-dirty instances will transition to
> hollow.]
>
> see below for comments.
>
> On Dec 8, 2005, at 4:52 AM, Michael Watzek wrote:
>
>> Hi Craig,
>>
>> please find the proposal for non-covered assertions in chapter 5.6.2
>> (Persistent-nontransactional-dirty) below. The proposal is based on
>> spec version 9/12/2005.
>>
>> Regards,
>> Michael
>>
>> Proposal:
>>
>> - Rename assertions A5.6.1-1 and A5.6.1-2 in this chapter to A5.6.2-1
>> and A5.6.2-2
>>
>> - A5.6.2-3 [At some future point, the application can begin a
>> transaction and incorporate the changes into the transactional
>> state. Committing the transaction makes the changes made outside the
>> transaction durable.]
>
>
> This assertion will be tested by the following assertions.
>
> Craig
>
>>
>> - A5.6.2-4 [A persistent-nontransactional-dirty instance transitions
>> to hollow if it is the parameter of evict or evictAll. This allows
>> the application to remove instances from the set of instances whose state
>> is to be committed to the datastore.]
>>
>> - A5.6.2-5 [If a datastore transaction is begun, commit will write
>> the changes to the datastore with no checking as to the current state
>> of the instances in the datastore. That is, the changes made outside
>> the transaction together with any changes made inside the transaction
>> will overwrite the current state of the datastore. The
>> persistent-nontransactional-dirty instances will transition according
>> to the RetainValues flag. With the RetainValues flag set to true,
>> persistent-nontransactional-dirty instances will transition to
>> persistent-nontransactional. With the RetainValues flag set to false,
>> persistent-nontransactional-dirty instances will transition to hollow.]
>>
>> - A5.6.2-6 [If a datastore transaction is begun, rollback will not
>> write any changes to the datastore. The
>> persistent-nontransactional-dirty instances will transition according
>> to the RestoreValues flag.
>> With the RestoreValues flag set to true,
>> persistent-nontransactional-dirty instances will make no state
>> transition, but the fields will be restored to their values as of the
>> beginning of the transaction, and any changes made within the
>> transaction will be discarded. With the RestoreValues flag set to
>> false, persistent-nontransactional-dirty instances will transition to
>> hollow.]
>>
>> - A5.6.2-7 [If an optimistic transaction is begun, commit will write
>> the changes to the datastore after checking as to the current state
>> of the instances in the datastore. The changes made outside the
>> transaction
>> together with any changes made inside the transaction will update the
>> current state of the datastore if the version checking is successful.
>> The persistent-nontransactional-dirty instances will transition
>> according to the RetainValues flag. With the RetainValues flag set to
>> true, persistentnontransactional-dirty instances will transition to
>> persistent-nontransactional. With the Retain-Values flag set to
>> false, persistent-nontransactional-dirty instances will transition to
>> hollow.]
>>
>> - A5.6.2-8 [If an optimistic transaction is begun, rollback will not
>> write any changes to the datastore. The
>> persistent-nontransactional-dirty instances will transition according
>> to the RestoreValues flag. With the RestoreValues flag set to true,
>> persistent-nontransactional-dirty instances will make no state
>> transition, but the fields will be restored to their values as of the
>> beginning of the transaction, and any changes made within the
>> transaction will be discarded. With the RestoreValues flag set to
>> false, persistent-nontransactional-dirty instances will transition to
>> hollow.]
>>
>> --
>> -------------------------------------------------------------------
>> 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!
>
Re: Proposal for non-covered assertions in chapter 5.6.2
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Michael,
Thanks. I've updated the spec with new assertion numbers.
JDO instances that represent specific persistent data in the
datastore, whose values may be currently loaded but not
transactionally consistent, and have been modified since the last
commit, are persistent-nontransactional-dirty. A5.6.2-1 [ There is a
JDO Identity associated with these instances], and A5.6.2-2
[ transactional instances can be obtained from the object ids.]
The persistent-nontransactional-dirty state allows applications to
operate on nontransactional instances in the cache and make changes
to the instances without having a transaction active. At some future
point, the application can begin a transaction and incorporate the
changes into the transactional state. Committing the transaction
makes the changes made outside the transaction durable.
A5.6.2-3 [ A persistent-nontransactional-dirty instance transitions
to hollow if it is the parameter of evict or evictAll. This allows
the application to remove instances from the set of instances whose
state is to be committed to the datastore.]
A5.6.2-4 [ If a datastore transaction is begun, commit will write the
changes to the datastore with no checking as to the current state of
the instances in the datastore. That is, the changes made outside the
transaction together with any changes made inside the transaction
will overwrite the current state of the datastore. The persistent-
nontransactional-dirty instances will transition according to the
RetainValues flag. With the RetainValues flag set to true, persistent-
nontransactional-dirty instances will transition to persistent-
nontransactional. With the RetainValues flag set to false, persistent-
nontransactional-dirty instances will transition to hollow. ]
A5.6.2-5 [ If a datastore transaction is begun, rollback will not
write any changes to the datastore. The persistent-nontransactional-
dirty instances will transition according to the RestoreValues flag.
With the RestoreValues flag set to true, persistent-nontransactional-
dirty instances will make no state transition, but the fields will be
restored to their values as of the beginning of the transaction, and
any changes made within the transaction will be discarded. With the
RestoreValues flag set to false, persistent-nontransactional-dirty
instances will transition to hollow.]
A5.6.2-6 [ If an optimistic transaction is begun, commit will write
the changes to the datastore after checking as to the current state
of the instances in the datastore. The changes made outside the
transaction together with any changes made inside the transaction
will update the current state of the datastore if the version
checking is successful. The persistent-nontransactional-dirty
instances will transition according to the RetainValues flag. With
the RetainValues flag set to true, persistent-nontransactional-dirty
instances will transition to persistent-nontransactional. With the
RetainValues flag set to false, persistent-nontransactional-dirty
instances will transition to hollow. ]
A5.6.2-7 [ If an optimistic transaction is begun, rollback will not
write any changes to the datastore. The persistent-nontransactional-
dirty instances will transition according to the RestoreValues flag.
With the RestoreValues flag set to true, persistent-nontransactional-
dirty instances will make no state transition, but the fields will be
restored to their values as of the beginning of the transaction, and
any changes made within the transaction will be discarded. With the
RestoreValues flag set to false, persistent-nontransactional-dirty
instances will transition to hollow.]
see below for comments.
On Dec 8, 2005, at 4:52 AM, Michael Watzek wrote:
> Hi Craig,
>
> please find the proposal for non-covered assertions in chapter
> 5.6.2 (Persistent-nontransactional-dirty) below. The proposal is
> based on spec version 9/12/2005.
>
> Regards,
> Michael
>
> Proposal:
>
> - Rename assertions A5.6.1-1 and A5.6.1-2 in this chapter to
> A5.6.2-1 and A5.6.2-2
>
> - A5.6.2-3 [At some future point, the application can begin a
> transaction and incorporate the changes into the transactional
> state. Committing the transaction makes the changes made outside
> the transaction durable.]
This assertion will be tested by the following assertions.
Craig
>
> - A5.6.2-4 [A persistent-nontransactional-dirty instance
> transitions to hollow if it is the parameter of evict or evictAll.
> This allows the application to remove instances from the set of
> instances whose state
> is to be committed to the datastore.]
>
> - A5.6.2-5 [If a datastore transaction is begun, commit will write
> the changes to the datastore with no checking as to the current
> state of the instances in the datastore. That is, the changes made
> outside the transaction together with any changes made inside the
> transaction will overwrite the current state of the datastore. The
> persistent-nontransactional-dirty instances will transition
> according to the RetainValues flag. With the RetainValues flag set
> to true, persistent-nontransactional-dirty instances will
> transition to persistent-nontransactional. With the RetainValues
> flag set to false, persistent-nontransactional-dirty instances will
> transition to hollow.]
>
> - A5.6.2-6 [If a datastore transaction is begun, rollback will not
> write any changes to the datastore. The persistent-nontransactional-
> dirty instances will transition according to the RestoreValues flag.
> With the RestoreValues flag set to true, persistent-
> nontransactional-dirty instances will make no state transition, but
> the fields will be restored to their values as of the beginning of
> the transaction, and any changes made within the transaction will
> be discarded. With the RestoreValues flag set to false, persistent-
> nontransactional-dirty instances will transition to hollow.]
>
> - A5.6.2-7 [If an optimistic transaction is begun, commit will
> write the changes to the datastore after checking as to the current
> state of the instances in the datastore. The changes made outside
> the transaction
> together with any changes made inside the transaction will update
> the current state of the datastore if the version checking is
> successful. The persistent-nontransactional-dirty instances will
> transition
> according to the RetainValues flag. With the RetainValues flag set
> to true, persistentnontransactional-dirty instances will transition
> to persistent-nontransactional. With the Retain-Values flag set to
> false, persistent-nontransactional-dirty instances will transition
> to hollow.]
>
> - A5.6.2-8 [If an optimistic transaction is begun, rollback will
> not write any changes to the datastore. The persistent-
> nontransactional-dirty instances will transition according to the
> RestoreValues flag. With the RestoreValues flag set to true,
> persistent-nontransactional-dirty instances will make no state
> transition, but the fields will be restored to their values as of
> the beginning of the transaction, and any changes made within the
> transaction will be discarded. With the RestoreValues flag set to
> false, persistent-nontransactional-dirty instances will transition
> to hollow.]
>
> --
> -------------------------------------------------------------------
> 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!