> My question is why doesn't OJB return the same instance to various reads > of the same object within the same transaction?
Because in current version of OJB ObjectCache is the only service used to prevent object materialization from database (by using a Identity to Object mapping).
So if you set 'cacheable' false OJB does not know about a materialised object (Locking based on the Identity objects and does not 'cache' the objects by itself).
I'm not happy with this attribute, because it can cause problem on materialization of objects with references (circular references problem).
But in version 1.1 (maybe sooner) we will introduce a real smart two level cache, that will solve your described issue too.
regards, Armin
Luis Cruz wrote:
Hello,
We've been using OJB for well over a year now, and everyone on our team is very satisfied with this wonderful tool. Thanks goes out to every developer for all your hard work.
Today however we ran into a feature that until now we overlooked.
Please consider the following mapping:
<class-descriptor class="A" table="A"> <field-descriptor id="1" name="id" column="ID" jdbc-type="INTEGER" primarykey="true" autoincrement="true" /> <attribute attribute-name="cacheable" attribute-value="false" /> </class-descriptor>
For the above mapping, reading an object twice inside the the same transaction returns two different instances. Note that if the class was cacheable this would not be the case.
My question is why doesn't OJB return the same instance to various reads of the same object within the same transaction?
This is an issue for us because the following scenario occurs in our application:
// START OF EXAMPLE CODE beginTransaction();
...
A instance1 = read(A.class, idOfSomeA); tx.lock(instance1, Transaction.READ); doSomeVerifications(instance1);
...
A instance2 = read(A.class, idOfSomeA); tx.lock(instance2, Transaction.WRITE); instance2.setOtherFields(someNewValue);
confirmTransaction(); // END OF EXAMPLE CODE
What happens here is that alterations made upon instance2 (including the lock which is performed) are ignored because the transaction already has a reference to the object in question.
Any thoughts are appreciated, Luis Cruz
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
