db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michelle Caisse <Michelle.Cai...@Sun.COM>
Subject Re: Proposal for non-covered assertions in chapter 5.6.2
Date Fri, 09 Dec 2005 05:22:07 GMT
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!
>>
>
>


Mime
View raw message