Transaction Serializable CMP EJBs

Discussions

General J2EE: Transaction Serializable CMP EJBs

  1. Transaction Serializable CMP EJBs (3 messages)

    We have a CMP EJBs and we use 2 client programs that both try to modify the same record in the database.
    The bean is Transaction Serializable.
    Hence the client prog will lock the database while it is modifying the data. Hence the second client should wait for the first to finish its modification and then lock the database for its use.
    However this is not happening. The second client modifes the data even bfor the first's transaction is over.
    Attached is a snippet from the bean
    Note : we have used ejbgen

    /**
       *
       * @ejbgen:remote-method
    * isolation-level = TRANSACTION_SERIALIZABLE
       */

    public AttributeVO setAttribute(AttributeVO attributeVO, int ix) throws Exception
    {
    if(fgLoggingInfoEnabled)
    fgLoggingCategory.debug("Start of setAttribute");

    AttributeRW attributeRW = null;
            try
            {
                 attributeRW = getAttributeRWHome().findByPrimaryKey(attributeVO.id);
            }
            catch (FinderException e)
            {
               
            }

    boolean thereWasAnError = false;

    try
    {
    System.out.println("****************************************************");
    System.out.println("before call to set attribute");
    attributeRW.setAttribute(attributeVO, getUserId());


    System.out.println("before start of loop");
    for (int i=0;i<ix; i++)
    {
    System.out.println("Hi i is " + i);
    }
    System.out.println("after start of loop");

    System.out.println("****************************************************");
    System.out.println("After call to set attribute");

    Node node = getNodeHome().findByPrimaryKey(new Long("1"));

    attributeRW.setAttribute(attributeVO, getUserId());
    System.out.println("before start of loop ..... 2nd time");
    for (int i=0;i<ix; i++)
    {
    System.out.println(".... 2nd time Hi i is " + i);
    }
    AttributeVO returnAttributeVO = attributeRW.getVO();
    return returnAttributeVO;
    }
            catch (Exception e){thereWasAnError = true; throw e;}
            finally
            {
                if (thereWasAnError)
                {
                    fSessionContext.setRollbackOnly(); // abort the transaction.
                    
                }
            }
    }



  2. What database are you using? Not all databases implement pessimistic locking for serializable transactions. For instance, Oracle implements optimistic locking with version checking. This means that Oracle will allow two serializable transactions to modify the same record: the one that commits first will finish succesfully, and when the second one tries to commit it will fail with a "cannot serialize transaction" error.
    In Oracle, if you want to achieve a reader-blocks-reader effect, you can use a "SELECT ... FOR UPDATE" query. If your bean uses CMP, check out the App server's documentation to figure out how this can be done (some support it directly, some allow you to alter the generated SQL, etc).

    Gal
  3. When you say --

    when the second one tries to commit it will fail with a "cannot serialize transaction" error.

    what does it mean exactly. Why should the 2nd transaction fail ? Where will it get the version of the latest record in the database ?
    Are versions taken care of automatically in CMP's ? Do we have to code for them ?
    I think in BMP's we could do it programatically by checking the version. But how do we do this in CMP?
  4. Satish,

    I was referring to the concurrency control algorithm used for serializable transactions in Oracle databases. If a serializable transaction tries to update data that was changed since it started, it will fail with the "cannot serialize transaction" error. You don't have to take care of this yourself: the database itself manages the versions. This concurrency control algorithm ensures a reasonable level of consistency, while avoiding potentially expensive reader-blocks.

    Gal