You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Jair da Silva Ferreira Júnior <j2...@amazon.com.br> on 2003/12/30 23:15:58 UTC

objects in cache after transaction abort

Hi,
    I am using ojb1.0_rc5, ODMG api with OJB queries, mysql4 (innodb tables) in Linux Red Hat 7.3 (kernel 2.4.20-20.7).
    I moved from rc4 to rc5 recently and I noticed that sometimes the objects persisted inside an aborted transaction are still in cache when another transaction is started. Please, take a look at the above code to better undestand what I am saying:

   Transaction t=implementation.newTransaction();
   t.begin();
   Person e=new Person();
   t.lock(e,t.WRITE);
   e.setName("some exam");
    t.abort();   
   
    t=implementation.newTransaction();
   t.begin();   
    PersistenceBroker broker=((HasBroker)t).getBroker();
   QueryByIdentity query=new QueryByIdentity(e);
   Person loaded=(Person)broker.getObjectByQuery(query);
   boolean cacheOk=(loaded==null); //here cacheOk==false sometimes
   t.commit();


    This problem does not happen everytime. So, sometimes cacheOk==true.
    I wasn't able to reproduce this problem in a test case, but it does happen sometimes.

    This problem has never happened when I used rc4. 

    Here's my cache configuration in OJB.properties:

        ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
        descriptorBasedCaches=false

Thanks,
    Jair Jr

Re: objects in cache after transaction abort

Posted by Armin Waibel <ar...@code-au-lait.de>.
Hi,

 >     Is this fix going to be available in the final 1.0 version coming 
out in
 > 1 or 2 days?

yes, a fix or workaround

regards,
Armin

Jair da Silva Ferreira Júnior wrote:
> Hi Armin,
> 
> 
> 
>>Hi Jair jr,
>>
>>Jair da Silva Ferreira Júnior wrote:
>>
>>>Hi Armin,
>>>
>>>    Thank you for your fast reply.
>>>
>>>
>>>
>>>>hmm, this should not happend. Do you use checkpoint() or flush()
>>>>in your code?
>>>>This only could happens when the object was already in DB. Only the
>>>>PersistenceBrokerImpl and RsIterator class push objects to cache.
>>>>If you abort the tx, the PB instance is not aware of locked objects.
>>>
>>>
>>>    I use flush() and run an OJB query before aborting the transaction.
> 
> I
> 
>>>don't use checkpoint().
>>>
>>
>>If you call flush() all objects hold by ODMG-api are written to DB and
>>thus they are passed to the cache. If you now abort the tx the invalid
>>objects still in cache. Think this is a bug.
>>Thanks for the test case, reproduce the problem. Will check in a fix ASAP.
> 
> 
>     Is this fix going to be available in the final 1.0 version coming out in
> 1 or 2 days?
> 
> Thanks,
>     Jair Jr
> 
>>regards,
>>Armin
>>
>>
>>>>Interesting problem, please let me know if you can reproduce it.
>>>
>>>
>>>    I was able to reproduce the problem in the above test case. I hope
> 
> it
> 
>>>helps:
>>>
>>>  Transaction t=implementation.newTransaction();
>>>  t.begin();
>>>  PersistenceBroker broker=((HasBroker)t).getBroker();
>>>  Student s=new Student();
>>>  t.lock(s,t.WRITE);
>>>  s.setName("student");
>>>  s.setEmail("x@y.z");
>>>  s.setPassword("abcd");
>>>
>>>  ((TransactionExt)t).flush();
>>>
>>>  Criteria crit=new Criteria();
>>>  crit.addEqualTo("_name",s.getName());
>>>
>>>  QueryByCriteria query=QueryFactory.newQuery(Student.class,crit);
>>>
>>>  Iterator it=broker.getIteratorByQuery(query);
>>>  assertSame(s,it.next());
>>>  assertFalse(it.hasNext());
>>>  t.abort();
>>>
>>>  t=implementation.newTransaction();
>>>  t.begin();
>>>  broker=((HasBroker)t).getBroker();
>>>  QueryByIdentity query2=new QueryByIdentity(s);
>>>  boolean cacheOk=(broker.getObjectByQuery(query2)==null);
>>>  System.out.println("cacheOk: "+cacheOk); //cacheOk==false always
>>>  t.commit();
>>>
>>>Thanks,
>>>    Jair Jr
>>>
>>>
>>>
>>>>Jair da Silva Ferreira Júnior wrote:
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>>   I am using ojb1.0_rc5, ODMG api with OJB queries, mysql4 (innodb
>>>
>>>tables) in Linux Red Hat 7.3 (kernel 2.4.20-20.7).
>>>
>>>
>>>>>   I moved from rc4 to rc5 recently and I noticed that sometimes the
>>>
>>>objects persisted inside an aborted transaction are still in cache when
>>>another transaction is started. Please, take a look at the above code to
>>>better undestand what I am saying:
>>>
>>>
>>>>>  Transaction t=implementation.newTransaction();
>>>>>  t.begin();
>>>>>  Person e=new Person();
>>>>>  t.lock(e,t.WRITE);
>>>>>  e.setName("some exam");
>>>>>   t.abort();
>>>>>
>>>>>   t=implementation.newTransaction();
>>>>>  t.begin();
>>>>>   PersistenceBroker broker=((HasBroker)t).getBroker();
>>>>>  QueryByIdentity query=new QueryByIdentity(e);
>>>>>  Person loaded=(Person)broker.getObjectByQuery(query);
>>>>>  boolean cacheOk=(loaded==null); //here cacheOk==false sometimes
>>>>>  t.commit();
>>>>>
>>>>>
>>>>>   This problem does not happen everytime. So, sometimes
> 
> cacheOk==true.
> 
>>>>>   I wasn't able to reproduce this problem in a test case, but it does
>>>
>>>happen sometimes.
>>>
>>>
>>>>>   This problem has never happened when I used rc4.
>>>>>
>>>>>   Here's my cache configuration in OJB.properties:
>>>>>
>>>>>
>>>
>>>ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
>>>
>>>
>>>>>       descriptorBasedCaches=false
>>>>>
>>>>>Thanks,
>>>>>   Jair Jr
>>>>>
>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>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
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>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
> 
> 
> 



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


Re: objects in cache after transaction abort

Posted by Jair da Silva Ferreira Júnior <j2...@amazon.com.br>.
Hi Armin,


> Hi Jair jr,
>
> Jair da Silva Ferreira Júnior wrote:
> > Hi Armin,
> >
> >     Thank you for your fast reply.
> >
> >
> >>hmm, this should not happend. Do you use checkpoint() or flush()
> >>in your code?
> >>This only could happens when the object was already in DB. Only the
> >>PersistenceBrokerImpl and RsIterator class push objects to cache.
> >>If you abort the tx, the PB instance is not aware of locked objects.
> >
> >
> >     I use flush() and run an OJB query before aborting the transaction.
I
> > don't use checkpoint().
> >
>
> If you call flush() all objects hold by ODMG-api are written to DB and
> thus they are passed to the cache. If you now abort the tx the invalid
> objects still in cache. Think this is a bug.
> Thanks for the test case, reproduce the problem. Will check in a fix ASAP.

    Is this fix going to be available in the final 1.0 version coming out in
1 or 2 days?

Thanks,
    Jair Jr
>
> regards,
> Armin
>
> >
> >>Interesting problem, please let me know if you can reproduce it.
> >
> >
> >     I was able to reproduce the problem in the above test case. I hope
it
> > helps:
> >
> >   Transaction t=implementation.newTransaction();
> >   t.begin();
> >   PersistenceBroker broker=((HasBroker)t).getBroker();
> >   Student s=new Student();
> >   t.lock(s,t.WRITE);
> >   s.setName("student");
> >   s.setEmail("x@y.z");
> >   s.setPassword("abcd");
> >
> >   ((TransactionExt)t).flush();
> >
> >   Criteria crit=new Criteria();
> >   crit.addEqualTo("_name",s.getName());
> >
> >   QueryByCriteria query=QueryFactory.newQuery(Student.class,crit);
> >
> >   Iterator it=broker.getIteratorByQuery(query);
> >   assertSame(s,it.next());
> >   assertFalse(it.hasNext());
> >   t.abort();
> >
> >   t=implementation.newTransaction();
> >   t.begin();
> >   broker=((HasBroker)t).getBroker();
> >   QueryByIdentity query2=new QueryByIdentity(s);
> >   boolean cacheOk=(broker.getObjectByQuery(query2)==null);
> >   System.out.println("cacheOk: "+cacheOk); //cacheOk==false always
> >   t.commit();
> >
> > Thanks,
> >     Jair Jr
> >
> >
> >>Jair da Silva Ferreira Júnior wrote:
> >>
> >>
> >>>Hi,
> >>>    I am using ojb1.0_rc5, ODMG api with OJB queries, mysql4 (innodb
> >
> > tables) in Linux Red Hat 7.3 (kernel 2.4.20-20.7).
> >
> >>>    I moved from rc4 to rc5 recently and I noticed that sometimes the
> >
> > objects persisted inside an aborted transaction are still in cache when
> > another transaction is started. Please, take a look at the above code to
> > better undestand what I am saying:
> >
> >>>   Transaction t=implementation.newTransaction();
> >>>   t.begin();
> >>>   Person e=new Person();
> >>>   t.lock(e,t.WRITE);
> >>>   e.setName("some exam");
> >>>    t.abort();
> >>>
> >>>    t=implementation.newTransaction();
> >>>   t.begin();
> >>>    PersistenceBroker broker=((HasBroker)t).getBroker();
> >>>   QueryByIdentity query=new QueryByIdentity(e);
> >>>   Person loaded=(Person)broker.getObjectByQuery(query);
> >>>   boolean cacheOk=(loaded==null); //here cacheOk==false sometimes
> >>>   t.commit();
> >>>
> >>>
> >>>    This problem does not happen everytime. So, sometimes
cacheOk==true.
> >>>    I wasn't able to reproduce this problem in a test case, but it does
> >
> > happen sometimes.
> >
> >>>    This problem has never happened when I used rc4.
> >>>
> >>>    Here's my cache configuration in OJB.properties:
> >>>
> >>>
> >
> > ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
> >
> >>>        descriptorBasedCaches=false
> >>>
> >>>Thanks,
> >>>    Jair Jr
> >>>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>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
> >
> >
> >
>
>
>
>
>
> ---------------------------------------------------------------------
> 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


Re: objects in cache after transaction abort

Posted by Armin Waibel <ar...@code-au-lait.de>.
Hi Jair jr,

Jair da Silva Ferreira Júnior wrote:
> Hi Armin,
> 
>     Thank you for your fast reply.
> 
> 
>>hmm, this should not happend. Do you use checkpoint() or flush()
>>in your code?
>>This only could happens when the object was already in DB. Only the
>>PersistenceBrokerImpl and RsIterator class push objects to cache.
>>If you abort the tx, the PB instance is not aware of locked objects.
> 
> 
>     I use flush() and run an OJB query before aborting the transaction. I
> don't use checkpoint().
> 

If you call flush() all objects hold by ODMG-api are written to DB and
thus they are passed to the cache. If you now abort the tx the invalid
objects still in cache. Think this is a bug.
Thanks for the test case, reproduce the problem. Will check in a fix ASAP.

regards,
Armin

> 
>>Interesting problem, please let me know if you can reproduce it.
> 
> 
>     I was able to reproduce the problem in the above test case. I hope it
> helps:
> 
>   Transaction t=implementation.newTransaction();
>   t.begin();
>   PersistenceBroker broker=((HasBroker)t).getBroker();
>   Student s=new Student();
>   t.lock(s,t.WRITE);
>   s.setName("student");
>   s.setEmail("x@y.z");
>   s.setPassword("abcd");
> 
>   ((TransactionExt)t).flush();
> 
>   Criteria crit=new Criteria();
>   crit.addEqualTo("_name",s.getName());
> 
>   QueryByCriteria query=QueryFactory.newQuery(Student.class,crit);
> 
>   Iterator it=broker.getIteratorByQuery(query);
>   assertSame(s,it.next());
>   assertFalse(it.hasNext());
>   t.abort();
> 
>   t=implementation.newTransaction();
>   t.begin();
>   broker=((HasBroker)t).getBroker();
>   QueryByIdentity query2=new QueryByIdentity(s);
>   boolean cacheOk=(broker.getObjectByQuery(query2)==null);
>   System.out.println("cacheOk: "+cacheOk); //cacheOk==false always
>   t.commit();
> 
> Thanks,
>     Jair Jr
> 
> 
>>Jair da Silva Ferreira Júnior wrote:
>>
>>
>>>Hi,
>>>    I am using ojb1.0_rc5, ODMG api with OJB queries, mysql4 (innodb
> 
> tables) in Linux Red Hat 7.3 (kernel 2.4.20-20.7).
> 
>>>    I moved from rc4 to rc5 recently and I noticed that sometimes the
> 
> objects persisted inside an aborted transaction are still in cache when
> another transaction is started. Please, take a look at the above code to
> better undestand what I am saying:
> 
>>>   Transaction t=implementation.newTransaction();
>>>   t.begin();
>>>   Person e=new Person();
>>>   t.lock(e,t.WRITE);
>>>   e.setName("some exam");
>>>    t.abort();
>>>
>>>    t=implementation.newTransaction();
>>>   t.begin();
>>>    PersistenceBroker broker=((HasBroker)t).getBroker();
>>>   QueryByIdentity query=new QueryByIdentity(e);
>>>   Person loaded=(Person)broker.getObjectByQuery(query);
>>>   boolean cacheOk=(loaded==null); //here cacheOk==false sometimes
>>>   t.commit();
>>>
>>>
>>>    This problem does not happen everytime. So, sometimes cacheOk==true.
>>>    I wasn't able to reproduce this problem in a test case, but it does
> 
> happen sometimes.
> 
>>>    This problem has never happened when I used rc4.
>>>
>>>    Here's my cache configuration in OJB.properties:
>>>
>>>
> 
> ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
> 
>>>        descriptorBasedCaches=false
>>>
>>>Thanks,
>>>    Jair Jr
>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>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
> 
> 
> 





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


Re: objects in cache after transaction abort

Posted by Jair da Silva Ferreira Júnior <j2...@amazon.com.br>.
Hi Armin,

    Thank you for your fast reply.

> hmm, this should not happend. Do you use checkpoint() or flush()
> in your code?
> This only could happens when the object was already in DB. Only the
> PersistenceBrokerImpl and RsIterator class push objects to cache.
> If you abort the tx, the PB instance is not aware of locked objects.

    I use flush() and run an OJB query before aborting the transaction. I
don't use checkpoint().

>
> Interesting problem, please let me know if you can reproduce it.

    I was able to reproduce the problem in the above test case. I hope it
helps:

  Transaction t=implementation.newTransaction();
  t.begin();
  PersistenceBroker broker=((HasBroker)t).getBroker();
  Student s=new Student();
  t.lock(s,t.WRITE);
  s.setName("student");
  s.setEmail("x@y.z");
  s.setPassword("abcd");

  ((TransactionExt)t).flush();

  Criteria crit=new Criteria();
  crit.addEqualTo("_name",s.getName());

  QueryByCriteria query=QueryFactory.newQuery(Student.class,crit);

  Iterator it=broker.getIteratorByQuery(query);
  assertSame(s,it.next());
  assertFalse(it.hasNext());
  t.abort();

  t=implementation.newTransaction();
  t.begin();
  broker=((HasBroker)t).getBroker();
  QueryByIdentity query2=new QueryByIdentity(s);
  boolean cacheOk=(broker.getObjectByQuery(query2)==null);
  System.out.println("cacheOk: "+cacheOk); //cacheOk==false always
  t.commit();

Thanks,
    Jair Jr

> Jair da Silva Ferreira Júnior wrote:
>
> > Hi,
> >     I am using ojb1.0_rc5, ODMG api with OJB queries, mysql4 (innodb
tables) in Linux Red Hat 7.3 (kernel 2.4.20-20.7).
> >     I moved from rc4 to rc5 recently and I noticed that sometimes the
objects persisted inside an aborted transaction are still in cache when
another transaction is started. Please, take a look at the above code to
better undestand what I am saying:
> >
> >    Transaction t=implementation.newTransaction();
> >    t.begin();
> >    Person e=new Person();
> >    t.lock(e,t.WRITE);
> >    e.setName("some exam");
> >     t.abort();
> >
> >     t=implementation.newTransaction();
> >    t.begin();
> >     PersistenceBroker broker=((HasBroker)t).getBroker();
> >    QueryByIdentity query=new QueryByIdentity(e);
> >    Person loaded=(Person)broker.getObjectByQuery(query);
> >    boolean cacheOk=(loaded==null); //here cacheOk==false sometimes
> >    t.commit();
> >
> >
> >     This problem does not happen everytime. So, sometimes cacheOk==true.
> >     I wasn't able to reproduce this problem in a test case, but it does
happen sometimes.
> >
> >     This problem has never happened when I used rc4.
> >
> >     Here's my cache configuration in OJB.properties:
> >
> >
ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
> >         descriptorBasedCaches=false
> >
> > Thanks,
> >     Jair Jr
> >
>
>
>
> ---------------------------------------------------------------------
> 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


Re: objects in cache after transaction abort

Posted by Armin Waibel <ar...@code-au-lait.de>.
Hi Jair Jr,

hmm, this should not happend. Do you use checkpoint() or flush()
in your code?
This only could happens when the object was already in DB. Only the 
PersistenceBrokerImpl and RsIterator class push objects to cache.
If you abort the tx, the PB instance is not aware of locked objects.

Interesting problem, please let me know if you can reproduce it.

regards,
Armin

Jair da Silva Ferreira Júnior wrote:

> Hi,
>     I am using ojb1.0_rc5, ODMG api with OJB queries, mysql4 (innodb tables) in Linux Red Hat 7.3 (kernel 2.4.20-20.7).
>     I moved from rc4 to rc5 recently and I noticed that sometimes the objects persisted inside an aborted transaction are still in cache when another transaction is started. Please, take a look at the above code to better undestand what I am saying:
> 
>    Transaction t=implementation.newTransaction();
>    t.begin();
>    Person e=new Person();
>    t.lock(e,t.WRITE);
>    e.setName("some exam");
>     t.abort();   
>    
>     t=implementation.newTransaction();
>    t.begin();   
>     PersistenceBroker broker=((HasBroker)t).getBroker();
>    QueryByIdentity query=new QueryByIdentity(e);
>    Person loaded=(Person)broker.getObjectByQuery(query);
>    boolean cacheOk=(loaded==null); //here cacheOk==false sometimes
>    t.commit();
> 
> 
>     This problem does not happen everytime. So, sometimes cacheOk==true.
>     I wasn't able to reproduce this problem in a test case, but it does happen sometimes.
> 
>     This problem has never happened when I used rc4. 
> 
>     Here's my cache configuration in OJB.properties:
> 
>         ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
>         descriptorBasedCaches=false
> 
> Thanks,
>     Jair Jr
> 



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