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 Armin Waibel <ar...@code-au-lait.de> on 2004/01/02 23:07:03 UTC
Re: objects in cache after transaction abort
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 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