From jdo-dev-return-2443-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org Fri Dec 09 05:21:00 2005 Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 7999 invoked from network); 9 Dec 2005 05:20:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Dec 2005 05:20:59 -0000 Received: (qmail 35177 invoked by uid 500); 9 Dec 2005 05:20:59 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 35166 invoked by uid 99); 9 Dec 2005 05:20:59 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Dec 2005 21:20:59 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [192.18.98.36] (HELO brmea-mail-4.sun.com) (192.18.98.36) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Dec 2005 21:20:58 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jB95KbD7017581 for ; Thu, 8 Dec 2005 22:20:37 -0700 (MST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IR700D01T1KHS@mpk-mail1.sfbay.sun.com> (original mail from Michelle.Caisse@Sun.COM) for jdo-dev@db.apache.org; Thu, 08 Dec 2005 21:20:37 -0800 (PST) Received: from [129.150.24.244] (vpn-129-150-24-244.SFBay.Sun.COM [129.150.24.244]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IR70004LTIA82@mpk-mail1.sfbay.sun.com> for jdo-dev@db.apache.org; Thu, 08 Dec 2005 21:20:35 -0800 (PST) Date: Thu, 08 Dec 2005 21:22:07 -0800 From: Michelle Caisse Subject: Re: Proposal for non-covered assertions in chapter 5.6.2 In-reply-to: <43990B33.2000200@sun.com> To: jdo-dev@db.apache.org Message-id: <4399147F.7090309@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 References: <43982C98.6060909@spree.de> <10ABA8B9-853E-40A2-A960-B89A954680C8@Sun.COM> <43990B33.2000200@sun.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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! >> > >