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!
>>
>
>
|