Tom,
>> (1) As you know, my laptop is idle most of the time when running the
>> tests. As you told I have enabled a more detailed level of logging.
>> Would be great if you could have a look at the attached testresults.txt
>> file to find out why my machine's power is not used. I was a bit scared
>> by the fact that indeed the test is suspended. I expected lots of lines
>> pass before my eyes, but indeed two times it stops for long time!
>>
>> I noticed that it spent long time with doing nothing (no CPU / HD
>> activity, no RAM usage) after printing these lines:
>>
>> [junit] [TopLink Finer]:
>> ServerSession(9047389)--Thread(Thread[main,5,main])--client acquired
>> [junit] [TopLink Finer]:
>> ClientSession(15607307)--Connection(21048949)--Thread(Thread[main,5,main])--begin
>>
>> transaction
>> [junit] [TopLink Fine]:
>> ClientSession(15607307)--Connection(21048949)--Thread(Thread[main,5,main])--DELETE
>>
>> FROM CMP3_EMP_PROJ WHERE EXISTS(SELECT t0.EMP_ID FROM CMP3_EMPLOYEE t0,
>> CMP3_SALARY t1 WHERE ((t0.F_NAME = ?) AND (t1.EMP_ID = t0.EMP_ID)) AND
>> t0.EMP_ID = CMP3_EMP_PROJ.EMPLS_EMP_ID)
>> [junit] bind => [testRemoveFlushPersistContains]
> There are a number of places in the tests, when a query of this type
> runs. (A DELETE with this subquery). Are you just seeing it hang
> once, when the bind paramter is "testRemoveFlushPersistContains", or
> does it hang every time this type of SQL runs?
It only hangs that single time.
> I am wondering if this issue is related to the "Wayne Problem"
> referred to below. I see the SQL: t0.EMP_ID =
> CMP3_EMP_PROJ.EMPLS_EMP_ID, which I believe is an incarnation of this
> issue.
Maybe you are right and it might be gone once you checked in the fix for
"The Wayne Problem"?
>
>> Also the system was idle a long time after writing that lines:
>>
>> [junit] [TopLink Finer]:
>> ServerSession(19171705)--Thread(Thread[main,5,main])--client acquired
>> [junit] [TopLink Finer]:
>> ClientSession(10967412)--Thread(Thread[main,5,main])--acquire unit of
>> work: 19697685
>> [junit] [TopLink Finer]:
>> ClientSession(10967412)--Connection(8662426)--Thread(Thread[main,5,main])--begin
>>
>> transaction
>> [junit] [TopLink Fine]:
>> ClientSession(10967412)--Connection(8662426)--Thread(Thread[main,5,main])--DELETE
>>
>> FROM CMP3_BOAT
>> [junit] [TopLink Fine]:
>> ClientSession(10967412)--Connection(8662426)--Thread(Thread[main,5,main])--DELETE
>>
>> FROM CMP3_BICYCLE
>> [junit] [TopLink Fine]:
>> ClientSession(10967412)--Connection(8662426)--Thread(Thread[main,5,main])--DELETE
>>
>> FROM CMP3_NONFUEL_VEH
>> [junit] [TopLink Fine]:
>> ClientSession(10967412)--Connection(8662426)--Thread(Thread[main,5,main])--DELETE
>>
>> FROM CMP3_BUS
>> [junit] [TopLink Fine]:
>> ClientSession(10967412)--Connection(8662426)--Thread(Thread[main,5,main])--DELETE
>>
>> FROM CMP3_SPORTS_CAR
>>
>> I dropped the database, restarted my laptop, setup a new (clean)
>> database and run the test once more (which goes 46 Minutes, by the way,
>> about 40 of them doing nothing). It's reproducible. Always these two
>> steps are hanging.
>>
>>
>> I have no clue why it hangs, actually, and why it "somehow magically"
>> continues some minutes later. I thought it is some kind of database
>> deadlock, but in fact, it should be exactly the same time in both cases.
>> But it seems, the second hang is much, much longer than the first one.
> I am afraid I do not have a good idea why this is hanging on MaxDB
> (aside from my comment above). On my local Oracle run there is no
> perceptable slow down around those lines. I'll try to do a Derby run
> later to see if I see anything. Is there a chance that either MaxDB
> or the JDBC driver is having trouble with running these lines?
I could not imagine what problem MaxDB should have with a simple DELETE?
But I'll give it a try in my plain JDBC sample program.
>
>> (2) Unknown SQL objects
>>
>> [-4005] (at 116): Unknown column name:PROJECTS_PROJ_ID
>> [-4020] (at 8): Unknown sequence name:PROJECT_SEQ
>> [-4020] (at 8): Unknown sequence name:ADDRESS_SEQ
>> [-4020] (at 8): Unknown sequence name:BUYER_SEQ
>>
>> As you know, I had to rename some tables and this might be a follow-up,
>> but I am not sure. So it would be great if you could commit the needed
>> changes to cvs HEAD and let me know when done, so I will remove my own
>> (maybe buggy) changes and use the cvs HEAD then.
>>
> Just send your changes and I'll do my best to get them in soon.
I have sent them with separate email and give the tests another try once
you're done with the commit.
>
>> On the other hand, some of those names I never touched (e. g.
>> "PROJECT_SEQ", "ADDRESS_SEQ" and "BUYER_SEQ"), so this cannot be the
>> sole cause of the problems. I think that there are more bugs in the
>> tests, especially the "Unkown sequence name" seems to point out missing
>> CREATE SEQUENCE commands. In fact I did not find code that creates those
>> sequences in the test cases (maybe I missed it). What do you think?
> These sequence tables should be created at test startup by the ddl
> generation feature. The persistence.xml property: <property
> name="toplink.ddl-generation" value="drop-and-create-tables"/> enables
> this.
>
> I see the following error while the ddl generation seems to be
> executing. Perhaps this error is getting in the way of the successful
> completion of the DDL generation:
>
> [TopLink Warning]:
> ServerSession(24934792)--Thread(Thread[main,5,main])--Exception
> [TOPLINK-4002] (Oracle TopLink Essentials - 9.1 (Build
> ESSENTIALS_BUILD_NUMBER)):
> oracle.toplink.essentials.exceptions.DatabaseException
> Internal Exception: com.sap.dbtech.jdbc.exceptions.DatabaseException:
> [-3002] (at 219): Invalid datatypeError Code: -3002
> Call:CREATE TABLE CMP3_WRAPPER_TYPES (WT_ID INTEGER NOT NULL,
> DOUBLE_DATA DOUBLE PRECISION, BIGDECIMAL_DATA DOUBLE PRECISION,
> BOOLEAN_DATA BOOLEAN, BIGINTEGER_DATA DOUBLE PRECISION, LONG_DATA
> FIXED(20), CHARACTER_DATA CHAR UNICODE, STRING_DATA VARCHAR(255),
> INTEGER_DATA INTEGER, FLOAT_DATA FLOAT, SHORT_DATA BOOLEAN, BYTE_DATA
> BINARY(3), PRIMARY KEY (WT_ID))
> Query:DataModifyQuery()
>
> If we can narrow the issue down to this error, perhaps we can add a
> way to get more explicit errors is the DDL generation part of the test
> setup.
Great help, thank you! I will check that SQL statement with my JDBC test
application so we soon will see what the problem is. I expect it to be
my fault actually. Maybe I have a typo in a data type. Thanks a lot! :-)
>
>> (3) "The Wayne Problem"
>>
>> As I wrote before, Wayne's solution was correct. Would be great if you
>> could commit the fix for the "Waybe Problem" into the cvs HEAD, since I
>> do not know how to workaround it. Since I got a lot of those [-4005] (at
>> 116): Unknown column name:PROJECTS_PROJ_ID messages as you can see in
>> the attached file, this is really a blocker -- I have to skip lots of
>> those errors in the testresults.txt file to find my actual test
>> failures.
> I have entered the following Defect in the GlassFish Issue tracker:
>
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=1311
>
> I have marked in at a priority level that should put it close to the
> top of the stack of issues to be fixed.
Thank you for doing that. In fact I think that lots of follow-ups will
get fixed as a side effect. :-)
>
>> (4) Don't use comments but syntax
>>
>> As Martin FOWLER pointed out in his great reference manual on
>> refactoring, whenever possible syntax constraints should be used instead
>> of constraints in comments. In the case of DatabasePlatform.java this
>> should be applied:
>>
>> /**
>> * ...
>> * Don't override this method.
>> * ...
>> */
>> public boolean supportsTempTables() {...}
>>
>> should be changed to
>>
>> public final boolean supportsTempTable() {... }
>>
>> to enforce the constraint of not overriding the method (either it might
>> be overridden, or it shall not be overriden -- always be concise in your
>> code). Certainly this not only applies to this single place but to all
>> methods commented with "Don't override".
>>
>>
> Please feel free to enter an ENHANCEMENT in the GlassFish Issue tracker.
Good idea, thank you! :-)