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: JIRA JDO-13
Date Mon, 06 Jun 2005 18:10:49 GMT
Hi Michael,

Thanks for the analysis.

On Jun 6, 2005, at 10:05 AM, Michael Watzek wrote:

> Hi,
> JIRA JDO-13 was filed because a TCK test hangs  
> (org.apache.jdo.tck.lifecycle.PMsCanSharePCClassesButNotPCInstances).
> That TCK test starts 5 concurrent threads. Each thread makes an  
> object of class  
> "org.apache.jdo.tck.pc.lifecycle.StateTransitionObj" persistent in  
> a separate transaction. Afterwards, each thread waits for the other  
> threads to finish their transactions. After each threads has  
> finished its transaction, all threads continue execution.
> When such a thread makes an object persistent, it increases a  
> counter. After its transaction has finished, it checks that counter  
> and sleeps until the counter equals 5.
> Unfortunately, the code is not prepared for exceptions thrown while  
> transactions are executing. In such cases, the counter is not  
> increased and all threads wait forever.

Good catch.
> After I fixed this in my workspace, the exception points to the  
> problem:
> ERROR 42X05: Table 'STATETRANSITIONOBJ' does not exist.
> The files schema1.sql and schema2.sql do not contain that table.  
> Furthermore, I cannot find a .orm file in org/apache/jdo/tck/pc/ 
> lifecycle package for that class - neither for datastore identity  
> nor for application identity.
> There are .jdo files for both identities. Confusingly, the .jdo  
> file for application identity says datastore identity. I'm not sure  
> if this is a bug,

This is definitely a bug, left over from TCK 1.1. The file should be  
changed to use application identity, as support for datastore  
identity is just an option.

> as class "org.apache.jdo.tck.pc.lifecycle.StateTransitionObj" has  
> only two fields and, because of the field names, only one of them  
> seem to be persistent:
>     private int           int_field;
>     private transient int nonmanaged_field;
> However, the .jdo files say that both are persistent.

Not exactly. The .jdo files don't mention the fields, which means  
that int_field defaults to persistent, while the transient field  
defaults to non-persistent.

> Probably, these files do not comply to TCK20 conventions, as they  
> are no package jdo files?

They comply fine, as they are in the correct directory.
> If it is only one field which is persistent, do we have a problem  
> with application identity? In that case, the field must be the PK.

This is true, and the problem with it is that since it would be the  
PK, it cannot generally be written. Additionally there is no  
application identity class.
> Summarizing, in addition to the fix in the test code we need to
0.0 Fix the test case to catch exceptions and complete.
0.1 Fix the StateTransitionObject to add an int id field with  
application-created values, and add an embedded objectid class using  
the new field as primary key. (The default constructor should set the  
id field and increment the value to make it unique; the objectid  
class should be embedded and have the same int id field)
> 1) fix the SQL schema
> 2) add the missing .orm files
> 3) fix the .jdo files
> Eric, Andy, Michelle:
> I'm not sure, if the schema is autogenerated or if schema1.sql and/ 
> or schema2.sql is used. Can one of you fix the schema issue?

It's not generated. None of the schema in the TCK is generated. So  
far, it's all in schema1 and schema2 files.
> Craig:
> I'm not sure which fields of class  
> "org.apache.jdo.tck.pc.lifecycle.StateTransitionObj" are  
> persistent. Can you also help on the application/datastore issue?  
> Is it reasonable to define a second persistent field?

Yes, see above.

So, Michael,

If you have the JPOX environment set up, you should be able to fix  
the StateTransitionObj.java and the  
PMsCanSharePCClassesButNotPCInstances.java, the .jdo and .orm files.

Just coordinate with Michelle so you don't conflict on the  
schema1.sql and schema2.sql files. Since it's just adding a table,  
there should be minimal conflicts.


> Thanks,
> 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!

View raw message