pesimistic Lock semantic

#1

Hi

  I have tested pesimistic lock and the result was for me unexpected. In the first transaction i modified one object and in the second transaction i wanted to the same and  I got an exceptopn that lock could not be granted, quite nice but in that moment I wanted commit the first transaction and I also got lock exception. this the test:

 

public void testPesimisticLock() {
  PersistenceManager pm1 = null;
  PersistenceManager pm2 = null;

  try {
   pm1 = pmf.getPersistenceManager();
   pm1.currentTransaction().setOptimistic(false);
   pm1.currentTransaction().begin();
   long numOfPictures = countObjects(pm1, Picture.class);

   Picture picture1 = (Picture) readRandomObject(pm1, numOfPictures, Picture.class);
   picture1.setCanvas(new Square(picture1, 10));

   pm2 = pmf.getPersistenceManager();
   pm2.currentTransaction().setOptimistic(false);
   pm2.currentTransaction().begin();
   Picture picture2 = null;
   try {
    picture2 = (Picture) pm2.getObjectById(pm1.getObjectId(picture1));
    picture2.setCanvas(new Square(picture2, 20));
    pm2.currentTransaction().commit();
   } catch (JDOUserException e1) {
    pm1.currentTransaction().commit();
    pm2.currentTransaction().rollback();
    System.out.println(Thread.currentThread().getName() + " --" + "Pesimistic lock succed");
    return;
   }
  
   pm1.currentTransaction().commit();
   System.out.println(Thread.currentThread().getName() + " --Pesimistic lock failed");
  } catch (JDOUserException e1){
   System.out.println(Thread.currentThread().getName() + " --Pesimistic lock failed " + e1.getMessage());
  }
  finally {
   if (pm1 != null) {
    if (pm1.currentTransaction().isActive())
     pm1.currentTransaction().rollback();
    pm1.close();
   }
   if (pm2 != null) {
    if (pm2.currentTransaction().isActive())
     pm2.currentTransaction().rollback();
    pm2.close();
   }
  }
}

 

br

Tomasz

#2

First, handling such issues is much more effective when a complete runnable program is provided - could you please apply the required changes to your almost runnable program?

Without a runnable program this is only a guess - but I think that you should have a problem if you run this code without enhancement. JDO (unlike JPA) requires enhancement to function properly.

With enhancement - the picture will be locked for WRITE by pm1 and exception is expected when pm2 tries to read the same object (on getObjectById before commit).

With reflection (when enhancement doesn't work from any reason) - the picture will be locked only for READ by pm1 then for READ by pm2 and then both commit would fail (as your description). This is because without enhancement tracking changes to objects at the time they happen is impossible (you can try help ObjectDB by invoking JDOHelper.makeDirty explicitly), so they are detected only on commit.

 

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)

Post Reply

To post a reply and/or subscribe to update notifications - please login