db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <Craig.Russ...@Sun.COM>
Subject Re: 4 non transactional read errors
Date Mon, 27 Jun 2005 20:37:47 GMT
Hi Michael,

On Jun 27, 2005, at 10:48 AM, Michael Bouschen wrote:

> Hi Craig,
>
>
>> Hi Michael,
>> On Jun 27, 2005, at 10:03 AM, Michael Watzek wrote:
>>
>>> Hi Craig,
>>>
>>> there are two tests throwing a JDOUserException ("Can't read  
>>> fields with outside of transactions. You may want to set  
>>> 'NontransactionalRead=true'.").
>>>
>>> The first test ("Retrieve.runTestRetrieve") begins a transaction,  
>>> retrieves fields of a pc instance, commits, and calls a getter  
>>> method on that instance.
>>>
>>> The second test ("HollowInstanceMaintainsPK.test") begins a  
>>> transaction,  makes an object persistent, commits, and calls a  
>>> getter method on that object.
>>>
>>  From the sound of it, it is the PK that is being read. If this is  
>> the case, then no transaction is required. PK fields can always be  
>> read, even for deleted instances.
>>
>>>
>>> Both tests seem to assume that non-transactional read is set.  
>>> Should we change the test cases and make the pc instances  
>>> transient before we call the getter?
>>>
>> No, nontransactional read is an optional feature, so we can't  
>> assume that it is supported. The correct fix is to start a  
>> transaction before reading the field, and commit the transaction  
>> after reading the field.
>>
>
> The first test Retrieve.runTestRetrieve tests PM's retrieve API. It  
> calls pm.retrieve, commits the transaction and then checks the  
> fields of the instance passed to pm.retrieve. If we start a  
> transaction before reading the field the state of the instance  
> might be reloaded. In this case we not actually check whether  
> pm.retrieve loads the correct values.
>
> The test method calls pm.retrieve for 3 instances. Two of them are  
> made transient before committing the transaction. Do you recall  
> whether there is a special reason for not making the third one  
> transient, too? If not I propose to make it transient and then we  
> do not need nontransactional read at all.

I don't recall any reason for the test not making the third instance  
transient so the fields can be checked. That sounds like a better fix  
than starting a tx.

Craig


>
> Regards Michael
>
>
>>>
>>> Furthermore, we have two errors  
>>> ("org.jpox.exceptions.TransactionNotActiveException: Transaction  
>>> is not active..."). Both test cases  
>>> ("IteratorHasNextFalseAfterExtentClose", "Iterators") iterate an  
>>> extent outside of a transactions. I can fix this also.
>>>
>> Yes, please fix these.
>> Thanks,
>> 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!
>>
>
>
> -- 
> Michael Bouschen        Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de    http://www.tech.spree.de/
> Tel.:++49/30/235 520-33        Buelowstr. 66
> Fax.:++49/30/2175 2012        D-10783 Berlin
>

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