Re: objects in cache after transaction abort

[Armin Waibel]

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]