[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/lock QueuedPessimisticEJBLock.java

2002-04-09 Thread Bill Burke 

  User: patriot1burke
  Date: 02/04/09 22:44:03

  Modified:src/main/org/jboss/ejb/plugins/lock
QueuedPessimisticEJBLock.java
  Log:
  read-only methods and read-only beans will now release transactional locks at the
  end of an invocation.
  
  Revision  ChangesPath
  1.9   +31 -29
jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java
  
  Index: QueuedPessimisticEJBLock.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- QueuedPessimisticEJBLock.java 12 Jan 2002 20:21:07 -  1.8
  +++ QueuedPessimisticEJBLock.java 10 Apr 2002 05:44:03 -  1.9
  @@ -14,7 +14,8 @@
   import javax.transaction.Status;
   
   import org.jboss.invocation.Invocation;
  -
  +import org.jboss.ejb.Container;
  +import org.jboss.ejb.EntityContainer;
   
   /**
* This class is holds threads awaiting the transactional lock to be free
  @@ -30,19 +31,29 @@
* When the reference count goes to 0, the lock is released from the
* id -> lock mapping.
*
  + * As of 04/10/2002, you can now specify in jboss.xml method attributes that define
  + * methods as read-only.  read-only methods(and read-only beans) will release 
transactional
  + * locks at the end of the invocation.  This decreases likelyhood of deadlock and 
increases
  + * performance.
  + *
* FIXME marcf: we should get solid numbers on this locking, bench in multi-thread 
environments
* We need someone with serious SUN hardware to run this lock into the ground
*
* @author Marc Fleury
* @author Bill Burke
  + * @author Peter Murray
*
  - * @version $Revision: 1.8 $
  + * @version $Revision: 1.9 $
*
* Revisions:
* 2001/08/03: billb
*  
*  Initial revision
*  
  + * 2002/04/10: billb 
  + *  
  + *  Applied Peter Murray's read-only locking mechanisms.
  + *  
*/
   public class QueuedPessimisticEJBLock extends BeanLockSupport
   {
  @@ -50,6 +61,7 @@
   
  private HashMap txLocks = new HashMap();
  private LinkedList txWaitQueue = new LinkedList();
  +   private boolean isReadOnlyTxLock = true;
   
  private int txIdGen = 0;
  private class TxLock
  @@ -136,6 +148,13 @@
/* loop on lock wakeup and restart trying to schedule */
threadScheduled = doSchedule(mi);
 }
  +  // Only set isReadOnlyTxLock if there was a transactional lock
  +  if (mi.getTransaction() != null)
  +  {
  + // Promote the txlock into a writeLock if we're not a readonly method
  + // isReadOnlyTxLock will be reset in nextTransaction()
  + isReadOnlyTxLock = isReadOnlyTxLock && 
(((EntityContainer)container).isReadOnly() || 
container.getBeanMetaData().isMethodReadOnly(mi.getMethod().getName()));
  +  }
  }
  /**
   * doSchedule(Invocation)
  @@ -382,7 +401,7 @@
 }
   
 this.tx = null;
  -  
  +  this.isReadOnlyTxLock = true;
 // is there a waiting list?
 if (!txWaitQueue.isEmpty())
 {
  @@ -422,48 +441,31 @@
   * if we reach the count of zero it means the instance is free from threads (and 
reentrency)
   * we wake up the next thread in the currentLock
   */
  -   public void releaseMethodLock() 
  +   public void endInvocation(Invocation mi)
  { 
 numMethodLocks--;
 if (numMethodLocks == 0)
 {
synchronized(methodLock) {methodLock.notify();}
  -  } 
  -   }
  -   
  -   /*
  -* For debugging purposes
  -   private static int filecount = 0;
  -   
  -   private static synchronized void saveStackTrace(String msg)
  -   {
  -  System.out.println("saving stack trace");
  -  try
  -  {
  - FileOutputStream fp = new FileOutputStream("d:/tmp/stacktraces/" + 
Integer.toString(filecount++) + ".txt");
  - PrintStream ps = new PrintStream(fp);
  - ps.println(msg);
  - new Throwable().printStackTrace(ps);
  - ps.close();
  - fp.close();
  + if (isReadOnlyTxLock && mi.getTransaction() != null)
  + {
  +if (isReadOnlyTxLock)
  +{
  +   endTransaction(mi.getTransaction());
  +}
  + }
 }
  -  catch (Exception ignored) {}
  -  System.out.println("done saving stack trace");
  -
  }
  -   */
  -
  +   
  public void removeRef() 
  { 
 refs--;
 if (refs == 0 && txWaitQueue.size() > 0) 
 {
  - // saveStackTrace("removing bean lock and it has tx's in 
QUEUE!***");
throw new IllegalStateException("removing bean lock and it has tx's in 
QUEUE!");
 }
 else if (refs == 0 && this.tx != null) 
 {
  - // saveStackTrace("removing bean loc

[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/lock QueuedPessimisticEJBLock.java BeanLockSupport.java

2002-01-12 Thread Bill Burke 

  User: patriot1burke
  Date: 02/01/12 12:21:07

  Modified:src/main/org/jboss/ejb/plugins/lock
QueuedPessimisticEJBLock.java BeanLockSupport.java
  Log:
  Added deadlock detection.  If application deadlock is detected and RuntimeException 
is thrown so
  that the thread does not hang until TX timeout.  It will be extremely helpful in 
debugging.
  
  Revision  ChangesPath
  1.8   +81 -54
jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java
  
  Index: QueuedPessimisticEJBLock.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- QueuedPessimisticEJBLock.java 2001/12/19 06:04:48 1.7
  +++ QueuedPessimisticEJBLock.java 2002/01/12 20:21:07 1.8
  @@ -36,7 +36,7 @@
* @author Marc Fleury
* @author Bill Burke
*
  - * @version $Revision: 1.7 $
  + * @version $Revision: 1.8 $
*
* Revisions:
* 2001/08/03: billb
  @@ -238,59 +238,85 @@
  protected boolean waitForTx(Transaction miTx, boolean trace) throws Exception
  {
 boolean wasScheduled = false;
  -
  -  // Do we have a running transaction with the context?
  -  // We loop here until either until success or until transaction timeout
  -  // If we get out of the loop successfully, we can successfully
  -  // set the transaction on this puppy.
  -  while (this.tx != null &&
  - // And are we trying to enter with another transaction?
  - !this.tx.equals(miTx))
  -  {
  - wasScheduled = true;
  - // That's no good, only one transaction per context
  - // Let's put the thread to sleep the transaction demarcation will wake 
them up
  - if( trace ) log.trace("Transactional contention on context"+id);
  - 
  - TxLock txLock = getTxLock(miTx);
  - 
  - if( trace ) log.trace("Begin wait on Tx="+this.tx);
  - 
  - // And lock the threads on the lock corresponding to the Tx in MI
  - synchronized(txLock)
  - {
  -releaseSync(); 
  -try
  -{
  -   txLock.wait(txTimeout);
  -} catch (InterruptedException ignored) {}
  - } // end synchronized(txLock)
  - 
  - this.sync();
  - 
  - if( trace ) log.trace("End wait on TxLock="+this.tx);
  - if (isTxExpired(miTx))
  - {
  -log.error(Thread.currentThread() + "Saw rolled back tx="+miTx+" waiting 
for txLock"
  -  // +" On method: " + mi.getMethod().getName()
  -  // +" txWaitQueue size: " + txWaitQueue.size()
  -  );
  -if (txLock.isQueued)
  -{
  -   // Remove the TxLock from the queue because this thread is exiting.
  -   // Don't worry about notifying other threads that share the same 
transaction.
  -   // They will timeout and throw the below RuntimeException
  -   txLocks.remove(txLock);
  -   txWaitQueue.remove(txLock);
  -}
  -else if (this.tx != null && tx.equals(miTx))
  -{
  -   // We're not qu
  -   nextTransaction();
  -}
  -throw new RuntimeException("Transaction marked for rollback, possibly a 
timeout");
  - }
  -  } // end while(tx!=miTx)
  +  boolean addedWaiting = false;
  +  try
  +  {
  +  // Do we have a running transaction with the context?
  +  // We loop here until either until success or until transaction timeout
  +  // If we get out of the loop successfully, we can successfully
  +  // set the transaction on this puppy.
  +  while (this.tx != null &&
  + // And are we trying to enter with another transaction?
  + !this.tx.equals(miTx))
  +  {
  + // For deadlock detection.
  + // miTx is waiting for this.tx to finish so put it
  + // in the waiting table and do deadlock detection.
  + if (miTx != null && !addedWaiting)
  + {
  +synchronized (waiting)
  +{
  +   waiting.put(miTx, this.tx);
  +   addedWaiting = true;
  +}
  +deadlockDetection(miTx);
  + }
  + wasScheduled = true;
  + // That's no good, only one transaction per context
  + // Let's put the thread to sleep the transaction demarcation will wake 
them up
  + if( trace ) log.trace("Transactional contention on context"+id);
  + 
  + TxLock txLock = getTxLock(miTx);
  + 
  + if( trace ) log.trace("Begin wait on Tx="+this.tx);
  + 
  + // And lock the threads on the lock correspo

[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/lock QueuedPessimisticEJBLock.java

2001-10-30 Thread marc fleury 

  User: mnf999  
  Date: 01/10/30 18:37:56

  Modified:src/main/org/jboss/ejb/plugins/lock
QueuedPessimisticEJBLock.java
  Log:
  Some Fixmes in the code, we are in a serious need of a cleanup imho...
  
  this code is starting to look green around the edge, a serious sign of decay
  
  Revision  ChangesPath
  1.5   +4 -1  
jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java
  
  Index: QueuedPessimisticEJBLock.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- QueuedPessimisticEJBLock.java 2001/09/11 18:35:01 1.4
  +++ QueuedPessimisticEJBLock.java 2001/10/31 02:37:56 1.5
  @@ -38,10 +38,13 @@
* When the reference count goes to 0, the lock is released from the
* id -> lock mapping.
*
  + * FIXME marcf: we should get solid numbers on this locking, bench in multi-thread 
environments
  + * We need someone with serious SUN hardware to run this lock into the ground
  + *
* @author Marc Fleury
* @author Bill Burke
*
  - * @version $Revision: 1.4 $
  + * @version $Revision: 1.5 $
*
* Revisions:
* 2001/08/03: billb
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/lock QueuedPessimisticEJBLock.java

2001-08-21 Thread Bill Burke 

  User: patriot1burke
  Date: 01/08/21 11:35:51

  Modified:src/main/org/jboss/ejb/plugins/lock
QueuedPessimisticEJBLock.java
  Log:
  Needed to set tx after obtaining lock
  
  Revision  ChangesPath
  1.3   +12 -9 
jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java
  
  Index: QueuedPessimisticEJBLock.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- QueuedPessimisticEJBLock.java 2001/08/08 22:13:00 1.2
  +++ QueuedPessimisticEJBLock.java 2001/08/21 18:35:51 1.3
  @@ -42,7 +42,7 @@
* @author Marc Fleury
* @author Bill Burke
*
  - * @version $Revision: 1.2 $
  + * @version $Revision: 1.3 $
*
* Revisions:
* 2001/08/03: billb
  @@ -156,10 +156,10 @@
  protected boolean doSchedule(MethodInvocation mi) 
 throws Exception
  {
  -  this.sync();
 boolean wasThreadScheduled = false;
 Transaction miTx = mi.getTransaction();
 boolean trace = log.isTraceEnabled();
  +  this.sync();
 try
 {
if( trace ) log.trace("Begin schedule, key="+mi.getId());
  @@ -249,9 +249,9 @@
 // We loop here until either until success or until transaction timeout
 // If we get out of the loop successfully, we can successfully
 // set the transaction on this puppy.
  -  while (tx != null &&
  +  while (this.tx != null &&
// And are we trying to enter with another transaction?
  - !tx.equals(miTx))
  + !this.tx.equals(miTx))
 {
wasScheduled = true;
// That's no good, only one transaction per context
  @@ -260,7 +260,7 @@

TxLock txLock = getTxLock(miTx);

  - if( trace ) log.trace("Begin wait on Tx="+tx);
  + if( trace ) log.trace("Begin wait on Tx="+this.tx);

// And lock the threads on the lock corresponding to the Tx in MI
synchronized(txLock)
  @@ -274,7 +274,7 @@

this.sync();

  - if( trace ) log.trace("End wait on TxLock="+tx);
  + if( trace ) log.trace("End wait on TxLock="+this.tx);
if (isTxExpired(miTx))
{
   log.error(Thread.currentThread() + "Saw rolled back tx="+miTx+" waiting 
for txLock"
  @@ -289,7 +289,7 @@
  txLocks.remove(txLock);
  txWaitQueue.remove(txLock);
   }
  -else if (tx != null && tx.equals(miTx))
  +else if (this.tx != null && tx.equals(miTx))
   {
  // We're not qu
  nextTransaction();
  @@ -297,6 +297,9 @@
   throw new RuntimeException("Transaction marked for rollback, possibly a 
timeout");
}
 } // end while(tx!=miTx)
  +
  +  // If we get here, this means that we have the txlock
  +  this.tx = miTx;
 return wasScheduled;
  }
   
  @@ -405,7 +408,7 @@
 if (numMethodLocks == 0)
 {
synchronized(methodLock) {methodLock.notify();}
  -  }
  +  } 
  }
  
  /*
  @@ -438,7 +441,7 @@
// saveStackTrace("removing bean lock and it has tx's in 
QUEUE!***");
throw new IllegalStateException("removing bean lock and it has tx's in 
QUEUE!");
 }
  -  else if (refs == 0 && tx != null) 
  +  else if (refs == 0 && this.tx != null) 
 {
// saveStackTrace("removing bean lock and it has tx set!***");
throw new IllegalStateException("removing bean lock and it has tx set!");
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/lock QueuedPessimisticEJBLock.java

2001-08-08 Thread Bill Burke 

  User: patriot1burke
  Date: 01/08/08 15:13:00

  Modified:src/main/org/jboss/ejb/plugins/lock
QueuedPessimisticEJBLock.java
  Log:
  add Marc as an author since he deserves most of the credit here.
  
  Revision  ChangesPath
  1.2   +2 -1  
jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java
  
  Index: QueuedPessimisticEJBLock.java
  ===
  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- QueuedPessimisticEJBLock.java 2001/08/08 22:02:21 1.1
  +++ QueuedPessimisticEJBLock.java 2001/08/08 22:13:00 1.2
  @@ -39,9 +39,10 @@
* When the reference count goes to 0, the lock is released from the
* id -> lock mapping.
*
  + * @author Marc Fleury
* @author Bill Burke
*
  - * @version $Revision: 1.1 $
  + * @version $Revision: 1.2 $
*
* Revisions:
* 2001/08/03: billb
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/lock QueuedPessimisticEJBLock.java

2001-08-08 Thread Bill Burke 

  User: patriot1burke
  Date: 01/08/08 15:02:21

  Added:   src/main/org/jboss/ejb/plugins/lock
QueuedPessimisticEJBLock.java
  Log:
  new FIFO txWait queue.  Should have better performance
  
  Revision  ChangesPath
  1.1  
jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java
  
  Index: QueuedPessimisticEJBLock.java
  ===
  /*
  * JBoss, the OpenSource EJB server
  *
  * Distributable under LGPL license.
  * See terms of license at gnu.org.
  */
  
  package org.jboss.ejb.plugins.lock;
  
  import java.util.LinkedList;
  import java.util.HashMap;
  import java.util.Collections;
  import java.lang.reflect.Method;
  
  import javax.transaction.Transaction;
  import javax.transaction.Status;
  import javax.transaction.Synchronization;
  import javax.transaction.TransactionManager;
  import javax.transaction.RollbackException;
  import javax.ejb.EJBObject;
  
  import org.jboss.ejb.MethodInvocation;
  import org.jboss.logging.log4j.JBossCategory;
  
  import java.io.FileOutputStream;
  import java.io.PrintStream;
  
  /**
   * This class is holds threads awaiting the transactional lock to be free
   * in a fair FIFO transactional queue.  Non-transactional threads
   * are also put in this wait queue as well. Unlike SimplePessimisticEJBLock which 
notifies all
   * threads on transaction completion, this class pops the next waiting transaction 
from the queue
   * and notifies only those threads waiting associated with that transaction.  This
   * class should perform better than Simple on high contention loads.
   * 
   * Holds all locks for entity beans, not used for stateful. 
   *
   * All BeanLocks have a reference count.
   * When the reference count goes to 0, the lock is released from the
   * id -> lock mapping.
   *
   * @author Bill Burke
   *
   * @version $Revision: 1.1 $
   *
   * Revisions:
   * 2001/08/03: billb
   *  
   *  Initial revision
   *  
   */
  public class QueuedPessimisticEJBLock extends BeanLockSupport
  {
 private Object methodLock = new Object();
  
 private HashMap txLocks = new HashMap();
 private LinkedList txWaitQueue = new LinkedList();
  
 private int txIdGen = 0;
 private class TxLock
 {
  
public Transaction tx = null;
public int id = 0;
public String threadName;
public boolean isQueued;
public TxLock(Transaction tx)
{
   this.threadName = Thread.currentThread().toString();
   this.tx = tx;
   if (tx == null)
   {
  if (txIdGen < 0) txIdGen = 0;
  this.id = txIdGen++;
   }
   this.isQueued = true;
}
  
public boolean equals(Object obj)
{
   if (obj == this) return true;
  
   TxLock lock = (TxLock)obj;
  
   if (lock.tx == null && this.tx == null)
   {
  return lock.id == this.id;
   }
   else if (lock.tx != null && this.tx != null)
   {
  return lock.tx.equals(this.tx);
   }
   return false;
}
  
public int hashCode()
{
   return this.id;
}
  
 }
  
 protected TxLock getTxLock(Transaction miTx)
 {
TxLock lock = null;
if (miTx == null)
{
   // There is no transaction
   lock = new TxLock(null);
   txWaitQueue.addLast(lock);
}
else
{
   TxLock key = new TxLock(miTx);
   lock = (TxLock)txLocks.get(key);
   if (lock == null)
   {
  txLocks.put(key, key);
  txWaitQueue.addLast(key);
  lock = key;
   }
}
return lock;
 }
  
 protected boolean isTxExpired(Transaction miTx) throws Exception
 {
if (miTx != null && miTx.getStatus() == Status.STATUS_MARKED_ROLLBACK)
{
   return true;
}
return false;
 }
  
  
 public void schedule(MethodInvocation mi) throws Exception
 {
boolean threadScheduled = false;
while (!threadScheduled)
{
   /* loop on lock wakeup and restart trying to schedule */
   threadScheduled = doSchedule(mi);
}
 }
 /**
  * doSchedule(MethodInvocation)
  * 
  * doSchedule implements a particular policy for scheduling the threads coming 
in. 
  * There is always the spec required "serialization" but we can add custom 
scheduling in here
  *
  * Synchronizing on lock: a failure to get scheduled must result in a wait() call 
and a 
  * release of the lock.  Schedulation must return with lock.
  * 
  */
 protected boolean doSchedule(MethodInvocation mi) 
throws Exception
 {
this.sync();
boolean wasThreadScheduled = false;
Transaction miTx = mi.getTransaction();
boolean