Re: objects in cache after transaction abort
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("[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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: objects in cache after transaction abort
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]
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("[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]
Re: objects in cache after transaction abort
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("[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]
Re: objects in cache after transaction abort
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
