You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Michael Watzek <mw...@spree.de> on 2006/01/16 16:17:05 UTC

Proposal for JDO-259

Hi,

JDO-259 contains 4 assertions related to state 
persistent-nontransactional-dirty. Below, you find a proposal on how 
these assertions may be implemented.

Please note, that these assertions do not specify life cycle 
transitions. Instead, they specify flushing of 
persistent-nontransactional-dirty instances into the datastore at 
commit/rollback. For this reason, I propose to implement new test cases 
instead of incorporating the test cases into the existing life cycle tests.

-----------

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.]

Test case:

// initially make an instance persistent
pm1.begin
pm1.makePersistent(pc)
oid = pm1.getObjectId(pc)
pm1.commit

// ensure concurrent changes of the instance in the datastore
pm2.begin
pc2 = pm2.getObjectById(oid)
modify(pc2)
pm2.commit

// make the instance persistent-nontransactional-dirty
modify(pc)

// flush the instance into the datastore
pm1.begin
pm1.commit

// check the state in the datastore
check(pm3.getObjectById(oid))

-----------

A5.6.2-6 [If a datastore transaction is begun, rollback will not write 
any changes to the datastore.]

Test case:

// initially make an instance persistent
pm1.begin
pm1.makePersistent(pc)
oid = pm1.getObjectId(pc)
pm1.commit

// make the instance persistent-nontransactional-dirty
modify(pc)

// discard the changes
pm1.begin
pm1.rollback

// check the state in the datastore
check(pm3.getObjectById(oid))

-----------

A5.6.2-8 [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.]

Test case w/o concurrent changes:

// initially make an instance persistent
pm1.begin
pm1.makePersistent(pc)
oid = pm1.getObjectId(pc)
pm1.commit

// make the instance persistent-nontransactional-dirty
modify(pc)

// flush the instance into the datastore
pm1.begin(optimistic==true)
pm1.commit

// check the state in the datastore
check(pm3.getObjectById(oid))


Test case w/ concurrent changes:

// initially make an instance persistent
pm1.begin
pm1.makePersistent(pc)
oid = pm1.getObjectId(pc)
pm1.commit

// ensure concurrent changes of the instance in the datastore
pm2.begin
pc2 = pm2.getObjectById(oid)
modify(pc2)
pm2.commit

// make the instance persistent-nontransactional-dirty
modify(pc)

// flush the instance into the datastore
pm1.begin(optimistic==true)
pm1.commit

// check the state in the datastore
check(pm3.getObjectById(oid))

-----------

A5.6.2-10 [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.]

Test case:

// initially make an instance persistent
pm1.begin
pm1.makePersistent(pc)
oid = pm1.getObjectId(pc)
pm1.commit

// make the instance persistent-nontransactional-dirty
modify(pc)

// discard the changes
pm1.begin(optimistic==true)
pm1.rollback

// check the state in the datastore
check(pm3.getObjectById(oid))

-----------

Questions:

1) The last assertion (A5.6.2-10) contains the sentence: "The 
persistent-nontransactional-dirty instances will transition according to 
the RestoreValues flag." I propose to drop the sentence from the 
assertion because the semantics of the RestoreValues flag is checked by 
other assertions related to JDO-258.

Regards,
Michael
-- 
-------------------------------------------------------------------
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/
-------------------------------------------------------------------

Re: Proposal for JDO-259

Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Michael,

On Jan 16, 2006, at 7:17 AM, Michael Watzek wrote:

> Hi,
>
> JDO-259 contains 4 assertions related to state persistent- 
> nontransactional-dirty. Below, you find a proposal on how these  
> assertions may be implemented.
>
> Please note, that these assertions do not specify life cycle  
> transitions. Instead, they specify flushing of persistent- 
> nontransactional-dirty instances into the datastore at commit/ 
> rollback. For this reason, I propose to implement new test cases  
> instead of incorporating the test cases into the existing life  
> cycle tests.

Right. These are behavior assertions that should be distinct from  
lifecycle assertions and should be in a separate test from the  
lifecycle tests.
>
> -----------
>
> 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.]
>
> Test case:
>
> // initially make an instance persistent
> pm1.begin
> pm1.makePersistent(pc)
> oid = pm1.getObjectId(pc)
> pm1.commit
>
> // ensure concurrent changes of the instance in the datastore
> pm2.begin
> pc2 = pm2.getObjectById(oid)
> modify(pc2)
> pm2.commit
>
> // make the instance persistent-nontransactional-dirty

Just for clarity, perhaps this modify block should be moved before  
the pm2 changes. Then it's clear that the state being modified is not  
in any way related to the changes in pm2.

> modify(pc)
>
> // flush the instance into the datastore
> pm1.begin
> pm1.commit
>
> // check the state in the datastore

It should match the changes made by pm1 not the changes made by pm2.

> check(pm3.getObjectById(oid))
>
> -----------
>
> A5.6.2-6 [If a datastore transaction is begun, rollback will not  
> write any changes to the datastore.]
>
> Test case:
>
> // initially make an instance persistent
> pm1.begin
> pm1.makePersistent(pc)
> oid = pm1.getObjectId(pc)
> pm1.commit
>
> // make the instance persistent-nontransactional-dirty
> modify(pc)
>
> // discard the changes
> pm1.begin
> pm1.rollback
>
> // check the state in the datastore
> check(pm3.getObjectById(oid))
>
> -----------
>
> A5.6.2-8 [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.]
>
> Test case w/o concurrent changes:
>
> // initially make an instance persistent
> pm1.begin
> pm1.makePersistent(pc)
> oid = pm1.getObjectId(pc)
> pm1.commit
>
> // make the instance persistent-nontransactional-dirty
> modify(pc)
>
> // flush the instance into the datastore
> pm1.begin(optimistic==true)
> pm1.commit
>
> // check the state in the datastore
> check(pm3.getObjectById(oid))
>
>
> Test case w/ concurrent changes:
>
> // initially make an instance persistent
> pm1.begin
> pm1.makePersistent(pc)
> oid = pm1.getObjectId(pc)
> pm1.commit
>
> // ensure concurrent changes of the instance in the datastore
> pm2.begin
> pc2 = pm2.getObjectById(oid)
> modify(pc2)
> pm2.commit
>
> // make the instance persistent-nontransactional-dirty
> modify(pc)
>
> // flush the instance into the datastore
> pm1.begin(optimistic==true)
> pm1.commit
>
> // check the state in the datastore
> check(pm3.getObjectById(oid))
>
> -----------
>
> A5.6.2-10 [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.]

The state transition should be a different assertion. See below.

>
> Test case:
>
> // initially make an instance persistent
> pm1.begin
> pm1.makePersistent(pc)
> oid = pm1.getObjectId(pc)
> pm1.commit
>
> // make the instance persistent-nontransactional-dirty
> modify(pc)
>
> // discard the changes
> pm1.begin(optimistic==true)
> pm1.rollback
>
> // check the state in the datastore
> check(pm3.getObjectById(oid))
>
> -----------
>
> Questions:
>
> 1) The last assertion (A5.6.2-10) contains the sentence: "The  
> persistent-nontransactional-dirty instances will transition  
> according to the RestoreValues flag." I propose to drop the  
> sentence from the assertion because the semantics of the  
> RestoreValues flag is checked by other assertions related to JDO-258.

I agree. The spec assertion is wrong. I've changed the spec as follows:

A5.6.2-10 [If an optimistic transaction is begun, rollback will not  
write any changes to the datastore. ] A5.6.2-11 [The persistent- 
nontransactional-dirty instances will transition according to the  
RestoreValues flag. ] A5.6.2-12 [With the RestoreValues flag set to  
true, persistent-nontransactional-dirty instances will make no state  
transition, ] A5.6.2-13 [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. ] A5.6.2-14 [With the  
RestoreValues flag set to false, persistent-nontransactional-dirty  
instances will transition to hollow.]

Craig
>
> Regards,
> Michael
> -- 
> -------------------------------------------------------------------
> 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!