Hi Bruce,
So did you get time to look into it ? Any solution ? Did you see the posting from
Micka�l ?
He was suggesting one solution.
Does he mean that "We should get ALL the doctors and pick the ones belonging to
the required
Department, either from within the program OR using a stored procedure". Even though
the latter is
the fastest, implementing that would bypass castor. Does it make a general solution ?
Waiting for your feedback.
Regards,
Arijit
Bruce Snyder wrote:
> 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
--
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
