Hi, I have the same problem and I haven't solved this problem yet.
When I use the PersistentLockMapImpl for my LockMapClass and I use collection proxy for all collection attributes of my classes, by your example, I found the hash code of the employee 'Jack' that looked up by OQL directly is different from the hash code of the employee 'Jack' that got from the project 'A'. So I think this could be the cause of your problem. But I neither don't know how to solve the problem. Could anyone help me? Thanks a million. To forgive my poor English. Simon >Lazy loading objects in collection property have different lock entry >with the object >load from ODMG API >OQL. But without lazy loading they have same lock entry. It confused me. >Condition: >There is a Project A with some Members. >Jack is member of Procject A. >Every member is an Employee. >Senario 1: >1.load Project A >2.load Employee Jack through the OQL command. >3.change some properties of Employee Jack >Result: The new property values of Employee Jack be updated into DB failed. > But if Jack be loaded from Project A's collection , the propertie value of >Jack can be changed and updated into DB succeed. >Senario 2: >1.load Employee Jack. >2.load Project A >3.change some properties of Employee Jack >Result: change succeed. >If the result above is the OJB design policy. We have to check our code carefully to >find out every >collection properties preventing Senario 1. >Following is my setting: >OJB.properties: LockMapClass=org.apache.ojb.odmg.locking.PersistentLockMapImpl > ImplicitLocking=true >repository_user.xml: collection-descriptor proxy attribute = true --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
