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