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 04:42:27 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message