1 Reply Latest reply on Oct 22, 2002 3:53 PM by adrian.brock

    Transaction Problem

    piboe

      Hi,

      I want to create a number of records in a database-table in let's call it a batch.

      To update the table I have an entity bean.
      The batch processing is managed by a stateless session bean that creates a lot of entity-bean instances (via the create method).

      The code below is a simplified part of my session-bean-method
      (all declarations are done before)

      ...
      for (int counter = 0; counter < primKeys.size(); counter++)
      {
      key = primKeys.get(counter);

      // Find the data in the source table
      mySourceRemote = mySourceHome.findByPrimaryKey(primKey);
      MyDataObject dataObject = mySourceRemote.getData();

      // Some processing

      myDestHome.create(dataObject );
      }

      ...

      For each item in the loop the data is successfully retrieved from the sourcetable and successfully stored in the destination table.
      My problem :
      Every time the create is executed, the container calls the ejbStore-method from all previous created entity-beans in the loop.
      OK, there's nothing to store an nothing will happen on the database but I don't want this overhead.
      Can anybody tell me why this happens ?

      The entity bean has transaction attribute : Required.
      So the transaction starts when the session-bean-method is called and ends at the end of this method.
      All creates are in the same transaction.


      Thanx for your help,
      Piboe

        • 1. Re: Transaction Problem

          findBy has to flush changed cached data
          because the query is executed against the database.

          The ejbStore is called to check whether the beans
          in the transaction have been changed, which in
          your case they haven't.

          I wonder if there should be an optimization for
          findByPrimaryKey?
          Suggest it in the CMP forum, one the CMP developers
          can probably answer better than me.

          Regards,
          Adrian