Hi Michael,On Jun 14, 2005, at 2:43 AM, Michael Watzek wrote: Hi Craig,
the test case you are describing seems to be the same as the ones of JIRA JDO-59. In the case of JIRA JDO-59, we have a synchronization bug in the test case preventing the real problem (lock wait timeout) from showing up.
I believe that the lock wait timeout shows up with the current level of checkins. Does it make sense to prepare a test case for the Derby guys that is implemented in pure SQL?
Yes, a simple JDBC test case just like the existing JDO-59 test case, with two threads and a DataSource that gives two Connection instances.
If you can write this in a few hours it will help. The Derby folks can't reproduce it :-(
Thanks,
Craig
Regards, Michael
Begin forwarded message:
*Date: *June 13, 2005 9:57:55 AM PDT *Subject: **Auto generation of database keys*
Hi,
I'm running into a locking issue when using generated keys. My primary key column is defined as DATASTORE_IDENTITY BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY. I don't care about the key being transactional. That is, if a transaction rolls back, I can live with the key that was allocated being permanently unused.
My application has two transactions inserting rows into the same table, and the threads have internal synchronization such that I need to have both insert statements succeed independently. The isolation level is the default.� Am I misusing the key generation? Can I get nontransactional key generation?
Thanks,
Craig
Craig Russell P.S. A good JDO? O, Gasp!
Craig Russell P.S. A good JDO? O, Gasp!
--� ------------------------------------------------------------------- Michael Watzek� � � � � � � � � [EMAIL PROTECTED] Engineering GmbH Tel.:� ++49/30/235 520 36 � � � 10783 Berlin - Germany -------------------------------------------------------------------
|
smime.p7s
Description: S/MIME cryptographic signature
