This one time, at band camp, Arijit Ghosh said: AG> Why do you think that the relation is Object to Object ? We have multiple doctors AG>belonging to a SINGLE department. So we have implemented it using 1-many relationship and AG>that means Object to Collection of Objects. Mapping.xml also says so.
My mistake, I noticed that it is one-to-many late last night. It was at that time that I noticed how tired I am ;-). Certainly not the first mistake I've made lately due to sleep deprivation. AG> This works PERFECTLY without any deadlock issue and Lazy Loading is set to TRUE. But the AG>problem creeps in as soon as I make this 1-many relationship as bi-directional. AG> AG> So this means that we have to access the doctors belonging to a department and ALSO the AG>department to which a doctor belongs. AG> AG> Well Bruce, so the realtion is not Object to Object but Object to Collection of Objects. AG>Right ? Yes, I was wrong. AG> I am having no problem with 1 to many relationship with Lazy loading set to true. AG> AG> Problem comes in, as I mentioned above, when I change it to bi-directional 1-many AG>relaitonship and this is our requirement. I'll need to debug this some more. I'll try to do this later tonight. Bruce AG>> This one time, at band camp, Arijit Ghosh said: AG>> AG>> AG> Did you have a look at the output for LAZY loading values ? AG>> AG>> Yes and it's apparent to me now that the relationship is object to AG>> object, not object to Collection of objects. The current lazy loading AG>> implementation in Castor only supports Collections, so lazy loading AG>> will definitely not work. AG>> AG>> AG> Do you want any other info from my side? Hope you get some solution for this AG>> AG>over the weekend. :) AG>> AG>> Have you tried to remove the bi-directional relation and only use AG>> a uni-directional relation? I know that the docs state that AG>> bi-directional relations are required, but the same paragraph also AG>> states that this is not enforced in all situations. In fact, the AG>> JDO examples demonstrate a uni-directional relation between Product AG>> and ProductGroup. AG>> AG>> AG> These are the outputs for different access modes that we tried --- AG>> AG> AG>> AG> AG>> AG>1. Access Mode = Exclusive AG>> AG> AG>> AG> Error Message : AG>> AG> AG>> AG>Exception Thread Lock conflict: attempt to load object of type Doctor with identity 2 AG>> AG>in two different locks modes (exclusive and non exclusive) in the same AG>> AG>transaction AG>> AG>java.lang.NullPointerException AG>> AG> at org.exolab.castor.persist.ClassMolder.revertObject(Unknown Source) AG>> AG> at org.exolab.castor.persist.LockEngine.revertObject(Unknown Source) AG>> AG> at org.exolab.castor.persist.TransactionContext.rollback(Unknown Source) AG>> AG> AG>> AG> at org.exolab.castor.jdo.engine.DatabaseImpl.close(Unknown Source) AG>> AG> at Test$OurThread.run(Test.java:141) AG>> AG>java.lang.NullPointerException AG>> AG> at org.exolab.castor.persist.ClassMolder.revertObject(Unknown Source) AG>> AG> at org.exolab.castor.persist.LockEngine.revertObject(Unknown Source) AG>> AG> at org.exolab.castor.persist.TransactionContext.rollback(Unknown Source) AG>> AG> AG>> AG> at org.exolab.castor.jdo.engine.DatabaseImpl.close(Unknown Source) AG>> AG> at Test$OurThread.run(Test.java:141) AG>> AG>Loaded Doc5 (499) AG>> AG>Exception Thread persist.writeLockTimeoutDepartment/1/5 by AG>> AG>org.exolab.castor.jdo.engine.TransactionContextImpl@5dcec6 AG>> AG> AG>> AG> AG>> AG>2. Access Mode = Shared AG>> AG> AG>> AG> Error Message : AG>> AG> AG>> AG>Loaded Doc6 (22) AG>> AG>Loaded Doc5 (499) AG>> AG>Loaded Doc2 (115) AG>> AG>Loaded Doc4 (1608) AG>> AG>Loaded Doc3 (454) AG>> AG>Committing Thread[Thread-5,5,main] AG>> AG>Committing Thread[Thread-1,5,main] AG>> AG>Committing Thread[Thread-3,5,main] AG>> AG>Committing Thread[Thread-2,5,main] AG>> AG>Committing Thread[Thread-4,5,main] AG>> AG>Successfully updated Doc5 (499) AG>> AG>Exception Thread Nested error: org.exolab.castor.jdo.LockNotGrantedException: AG>> AG>persist.deadlock AG>> AG>Exception Thread Nested error: org.exolab.castor.jdo.LockNotGrantedException: AG>> AG>persist.deadlock AG>> AG>Exception Thread Nested error: org.exolab.castor.jdo.LockNotGrantedException: AG>> AG>persist.deadlock AG>> AG>Successfully updated Doc2 (499) AG>> AG>> How exactly are these objects being used once they're loaded? Are AG>> you, by chance, using long transactions? If you're using long AG>> transactions, you could load the objects in the first transaction AG>> as read-only (oql.execute( Database.ReadOnly)) and update() the AG>> objects in the second transaction so that changes are committed. AG>> AG>> I'm just trying to think of anything that will help you. AG>> AG>> Bruce AG>> AG>> AG>Bruce Snyder wrote: AG>> AG> AG>> AG>> This one time, at band camp, Arijit Ghosh said: AG>> AG>> AG>> AG>> AG> We have filed the BUG report at Bugzilla. [ Bugzilla BUG ID : 1127 ] AG>> AG>> AG>> AG>> Thanks, Arjit. It helps to have the report for ease of reference. AG>> AG>> AG>> AG>> Upon thinking more about this situation, I've got more questions for you. AG>> AG>> AG>> AG>> 1) Have you tried to remove the bi-directional relations at all? Castor only AG>> AG>> enforces these in particular situations (of which I'm not entirely sure) and AG>> AG>> I've had a certain amount of success in the past by removing some of these. AG>> AG>> Keep in mind that upon removing these that the objects can only be navigated AG>> AG>> in one particular direction, not both. AG>> AG>> AG>> AG>> 2) Have you tried different locking modes? See http://www.castor.org/locking.html AG>> AG>> for more info. AG>> AG>> AG>> AG>> Also, a combination of these two may be something to consider as AG>> AG>> well. These are simply ideas to try as I'm not sure how they will affect AG>> AG>> your situation. AG>> AG>> AG>> AG>> Bruce AG>> AG>> -- AG>> AG>> perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");' AG>> AG>> AG>> AG>> ----------------------------------------------------------- AG>> AG>> If you wish to unsubscribe from this mailing, send mail to AG>> AG>> [EMAIL PROTECTED] with a subject of: AG>> AG>> unsubscribe castor-dev AG>> AG> AG>> AG>-- AG>> AG>ARIJIT GHOSH AG>> AG>Software Engineer AG>> AG>SOFTEX Group AG>> AG>TECHNOPARK, TVM AG>> AG> AG>> AG>----------------------------------------------------------- AG>> AG>If you wish to unsubscribe from this mailing, send mail to AG>> AG>[EMAIL PROTECTED] with a subject of: AG>> AG> unsubscribe castor-dev AG>> AG> AG>> AG>> -- AG>> AG>> perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");' AG>> AG>> ----------------------------------------------------------- AG>> If you wish to unsubscribe from this mailing, send mail to AG>> [EMAIL PROTECTED] with a subject of: AG>> unsubscribe castor-dev AG> AG>-- AG>ARIJIT GHOSH AG>Software Engineer AG>SOFTEX Group AG>TECHNOPARK, TVM AG> AG>----------------------------------------------------------- AG>If you wish to unsubscribe from this mailing, send mail to AG>[EMAIL PROTECTED] with a subject of: AG> unsubscribe castor-dev AG> -- perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");' ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
