db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Proposal for non-covered assertions in chapter 5.6.2
Date Fri, 09 Dec 2005 05:00:43 GMT
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!


Mime
View raw message