Multiple reads within the same transaction

[Luis Cruz <le...@netcabo.pt>]

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: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: Multiple reads within the same transaction

[Armin Waibel <ar...@code-au-lait.de>]

Hi Luis,

 > 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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
> 
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org