1 Reply Latest reply on May 27, 2004 6:01 PM by adrian.brock

    UserTransaction Concurrency

    humandoing

      Hello,

      I am doing some performance testing right now, and I am trying to figure out exactly how UserTransaction "does its thing". I have looked into the source code of ServerVMClientUserTransaction and TxManager, and have a few questions.

      I am using your standard UserTransaction type code as follows:

      transaction = (UserTransaction) myContext.lookup( "UserTransaction" );
      transaction.begin();
      //do junk
      //specifically, update 3-4 fields in a CMP Entity Bean
      // kicker - need to do the update for 10,000 - 125,000 entity beans
      transaction.commit();

      I have been performance testing various things, most notably, changing the number of CMP Beans updated in a given UserTransaction begin()....commit() session. Preliminary results indicate that updating 10-15 CMP Beans within a given UserTransaction gives me the best performance. Less than 10, or more than 20 seems to degredate the performance.

      Now what surprised me (and my CTO) is that multi-threading these updates does nothing to improve performance. So for example, I created a simple Thread class to iterate over CMP Beans that need updating, and update 10 CMP Beans per Transaction within the thread class. I create 5 instances of this thread class and run them simultaneously, each with their own set of 1/5 of the total number of CMP beans that need updating, each thread updating 10 CMP Beans per begin()....commit() session.

      One would think that (save some overhead due to lock contention) this solution should _vastly_ improve the overall performance, but in fact, there is no performance gain whatsoever.

      I am wondering if someone wiser than myself could explain this bizarre phenomenon, and perhaps suggest some other way in which I might be able to increase performance.

      Any suggestions or information is greatly appreciated.