Hello, I'm having a problem with long transactions. At this point I am grasping at straws looking for the reason. I apologize for the lengthy post, but I'd appreciate if anyone might see something in this scenario that jumps out as a clue.
I've found one item on the net that seems to be describing a similar problem. It is the "deep update" issue discussed in the "O/R Mapping with Castor JDO in the Real World" article at: http://portal.spiderlogic.com/modules.php?name=News&file=article&sid=16 I have a not-particularly-complex object hierarchy that is being persisted to RDBMS using Castor JDO. I used the example code in the Persistence interface methods of src/tests/jdo/TestPersistent.java as a model. The mapping seems to work - creates, deletes, and (some) updates are working. But some updates fail. I have unit tests that fail in a very consistent way. I'm familiar with the documentation on long transactions. My test system is single user, single execution thread, with no contention for persistent objects. The scenario is: 1An object hierarchy that consists of a top-level object that contains collections of other objects. Each of these other objects can in turn be "master" objects that contain "dependent" objects (see below). 2) The master/dependent relationships are 1:1 relationships that are managed from within the Persistence interface methods of the "master" object, rather than using the "dependent" mapping keyword. (...so the "master/dependent" relationships are technically "relationships between independent objects"). I do this because the dependent objects can have more than one different type of "master" object. For example, the "dependent" objects are created in the jdoBeforeCreate method of a "master" object. 3) When a transiently-created object hierarchy is "created", via a db.create() call on the top-level object, all the objects and relationships are persisted correctly. 4) When the object hierarchy is subsequently loaded, modified in transient space, and then "updated", via a db.update() call on the top-level object, Castor sometimes does not set the foreign keys in either the master or dependent object. (Both foreign keys are set to NULL). 5) In general (4) seems to happen when, from within a transaction, foreign keys are set in the Java objects before the referred-to objects have actually been created in the database. 6) Looking at the log files, it appears to me that the db.create() calls (on dependent objects) invoked from jdoBeforeCreate (of the master object) do not create the objects in a determinate order when invoked from a db.update() call. When the log files show that the dependent objects have been created before the master.jdoAfterCreate call completes, all the foreign keys are persisted correctly. When the log files show that the master.jdoAfterCreate call is invoked BEFORE the dependent objects are created, then the foreign keys are NULL. Any suggestions or clues on this issue would be greatly appreciated! Thanks, Rich Trevor ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-user
