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("[EMAIL PROTECTED]");
> > 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: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
