OpenJPA
  1. OpenJPA
  2. OPENJPA-172

DSRA9250E: Operation setTransactionIsolation is not allowed during a global transaction for Shareable Connections.

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.9.6
    • Fix Version/s: None
    • Component/s: jpa
    • Labels:
      None
    • Environment:
      Websphere 6.1 for zos and DB2 zos V8

      Description

      My persistence.xml looks like following

      *******************************************************************************************************
      <?xml version="1.0" ?>
      <persistence xmlns="http://java.sun.com/xml/ns/persistence"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      version="1.0">
      <persistence-unit name="dwtest" transaction-type="JTA">
      <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
      <non-jta-data-source>jdbc/ErwwDS</non-jta-data-source>
      <class>ejb.jpa.test.Customer</class>
      <class>ejb.jpa.test.District</class>
      <class>ejb.jpa.test.Warehouse</class>
      <class>ejb.jpa.test.History</class>
      <class>ejb.jpa.test.Item</class>
      <class>ejb.jpa.test.Neworders</class>
      <class>ejb.jpa.test.Orderline</class>
      <class>ejb.jpa.test.Orders</class>
      <class>ejb.jpa.test.Stock</class>
      <properties>

      <property name="openjpa.LockManager" value="pessimistic"/>
      <property name="openjpa.ReadLockLevel" value="read"/>
      <property name="openjpa.WriteLockLevel" value="write"/>
      <property name="openjpa.LockTimeout" value="30000"/>
      <property name="openjpa.FetchBatchSize" value="1" />
      <property name="openjpa.jdbc.TransactionIsolation" value="read-committed" />
      <property name="openjpa.Log" value="DefaultLevel=WARN, Runtime=INFO, Tool=INFO,SQL=TRACE"/>

      </properties>
      </persistence-unit>
      </persistence>
      *******************************************************************************************************************
      The Orderline entity looks like following

      *************************************************************************************************

      @Entity
      @IdClass(ejb.jpa.test.OrderlineId.class)
      @SequenceGenerator(name="mysequence",sequenceName="ORDER_ID")
      public class Orderline implements Serializable{

      @Id
      @GeneratedValue(strategy=GenerationType.SEQUENCE,generator="mysequence")
      java.lang.Integer ol_o_id = null;
      @Id
      java.lang.String ol_d_id = null;
      @Id
      java.lang.String ol_w_id = null;
      @Id
      java.lang.Short ol_number = null;
      java.lang.String ol_i_id = null;
      java.sql.Timestamp ol_delivery_d = null;
      java.lang.String ol_supply_w_id = null;
      java.lang.Short ol_quantity = null;
      java.math.BigDecimal ol_amount = null;
      java.sql.Timestamp itime = null;
      java.lang.String ol_dist_info = null;
      @ManyToOne(fetch=FetchType.LAZY)
      @JoinColumns(

      { @JoinColumn(name="ol_o_id", referencedColumnName="o_id"), @JoinColumn(name="ol_d_id", referencedColumnName="o_d_id"), @JoinColumn(name="ol_w_id", referencedColumnName="o_w_id") }

      )
      Orders orders = null;
      @ManyToOne(fetch=FetchType.LAZY)
      @JoinColumns(

      { @JoinColumn(name="ol_i_id", referencedColumnName="s_i_id"), @JoinColumn(name="ol_supply_w_id", referencedColumnName="s_w_id") }

      )
      Stock stock = null;

      *************************************************************************************************************************
      Now if I run the following client

      UserTransaction ut = null;
      ClientEJB facade = null;
      EntityManager em = null;
      try {
      Hashtable parms = new Hashtable();
      parms.put( Context.INITIAL_CONTEXT_FACTORY,
      "com.ibm.websphere.naming.WsnInitialContextFactory");
      InitialContext ctx = new InitialContext(parms);
      ut = (UserTransaction) ctx.lookup("java:comp/UserTransaction"); ut.begin();
      em = getFactory().createEntityManager ();

      try

      { OpenJPAEntityManager kem = OpenJPAPersistence.cast (em); kem.getFetchPlan().setReadLockMode(LockModeType.WRITE); stock = (Stock)kem.find(Stock.class,stockKey); kem.getFetchPlan().setReadLockMode(null); }

      catch (Exception fe) {}
      try {

      Timestamp itime = new Timestamp(System.currentTimeMillis());
      Orderline orderLine = new Orderline (districtId, warehouseId,
      new Short((short)ol_number), itemId,null, itemSupplyWarehouseId,new Short((short)itemQuantity), amount, itime, stockDistInfo);
      em.persist(orderLine);
      em.flush();

      ***************************************************************************************************************
      I get the the following stack trace, which appears to happen when we try to get the next value from Sequence
      [3/12/07 13:59:06:496 PDT] 00000020 SystemErr R 3073 TRACE [WebContainer : 0] openjpa.jdbc.SQL - <t 1503025558, conn 1348751460> executing prepstmnt 2134933312 SELECT t0.s_data, t0.s_dist_01, t0.s_dist_02, t0.s_dist_03, t0.s_dist_04, t0.s_dist_05, t0.s_dist_06, t0.s_dist_07, t0.s_dist_08, t0.s_dist_09, t0.s_dist_10, t0.s_order_cnt, t0.s_quantity, t0.s_remote_cnt, t0.s_ytd FROM Stock t0 WHERE t0.s_i_id = ? AND t0.s_w_id = ? WITH RS USE AND KEEP UPDATE LOCKS [params=(String) 000111, (String) 0001]
      [3/12/07 13:59:06:498 PDT] 00000020 SystemErr R 3075 TRACE [WebContainer : 0] openjpa.jdbc.SQL - <t 1503025558, conn 1348751460> [2 ms] spent
      [3/12/07 13:59:06:720 PDT] 00000020 SystemErr R javax.ejb.EJBException: ClientEJB: CreateException: OrderLineLocalHome create failed in placeNewOrder() of ClientEJB; nested exception is: <0|true|0.9.6-incubating> org.apache.openjpa.persistence.PersistenceException: DSRA9250E: Operation setTransactionIsolation is not allowed during a global transaction for Shareable Connections.
      <0|true|0.9.6-incubating> org.apache.openjpa.persistence.PersistenceException: DSRA9250E: Operation setTransactionIsolation is not allowed during a global transaction for Shareable Connections.
      at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3764)
      at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:94)
      at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:80)
      at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:56)
      at org.apache.openjpa.jdbc.kernel.AbstractJDBCSeq.next(AbstractJDBCSeq.java:59)
      at org.apache.openjpa.util.ImplHelper.generateValue(ImplHelper.java:159)
      at org.apache.openjpa.util.ImplHelper.generateFieldValue(ImplHelper.java:143)
      at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignField(JDBCStoreManager.java:554)
      at org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:435)
      at org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:420)
      at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignObjectId(JDBCStoreManager.java:538)
      at org.apache.openjpa.kernel.DelegatingStoreManager.assignObjectId(DelegatingStoreManager.java:131)
      at org.apache.openjpa.kernel.StateManagerImpl.assignObjectId(StateManagerImpl.java:471)
      at org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:2662)
      at org.apache.openjpa.kernel.PNewState.beforeFlush(PNewState.java:36)
      at org.apache.openjpa.kernel.StateManagerImpl.beforeFlush(StateManagerImpl.java:845)
      at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1865)
      at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1825)
      at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1609)
      at org.apache.openjpa.kernel.DelegatingBroker.flush(DelegatingBroker.java:959)
      at org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:438)
      at helpers.ClientEJB.placeNewOrder(Unknown Source)
      at erww.web.ErwwController.performServicesForNewOrder(ErwwController.java:550)
      at erww.web.ErwwController.performTask(ErwwController.java:272)
      at erww.web.ErwwController.doGet(ErwwController.java:85)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
      at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:966)

      Any idea why is this happening is this a bug.It appears like that while trying to get the next value from Sequence JPA tries to get a connection and then on the connection if the isolationLevel is not already READ_COMMITTED it tries to set it to READ_COMMITTED and that is where it blows out

      ritika

        Activity

        Hide
        Kevin Sutter added a comment -

        I believe Albert has verified that this problem no longer exists, but since he is out on vacation, I will just assign it to him and let him post his findings when he gets back. Since I'm not absolutely sure of the current state, this will not get resolved for the 1.0.0 release cutoff. I will change the release accordingly as well.

        Show
        Kevin Sutter added a comment - I believe Albert has verified that this problem no longer exists, but since he is out on vacation, I will just assign it to him and let him post his findings when he gets back. Since I'm not absolutely sure of the current state, this will not get resolved for the 1.0.0 release cutoff. I will change the release accordingly as well.
        Hide
        Kevin Sutter added a comment -

        Craig,
        This issue is related to OPENJPA-149, but it's not quite the same issue. The scenario is attempting to do a similar activity (database sequence numbering), but the results are different. OPENJPA-149 is concerned with being able to suspend a transaction. Some TranManagers allow for this, while others (like WebSphere) do not. But, WebSphere does provide a UOWSynchronizationRegistry which allows for "transaction suspend/resume" via a Runnable injection. Patrick would like to see this type of support more generalized in OpenJPA so that we could plug in other similar implementations. We have that on our plate.

        This Issue is related to what can or can not be set on a Shareable Connection once the associated transaction has started. For example, if you are sharing a connection with an isolation level of read-committed, you wouldn't want another application to change the isolation level out from under you in the middle of a transaction. So, WebSphere prevents operations like that from happening with shared connections. I'm surprised that other app servers don't act in the same manner, but to each their own.

        So, with this issue, we need to determine if the setting of isolation levels or auto commit or any other "non-shareable" property setting needs to be processed differently based on the environment.

        Thanks,
        Kevin

        Show
        Kevin Sutter added a comment - Craig, This issue is related to OPENJPA-149 , but it's not quite the same issue. The scenario is attempting to do a similar activity (database sequence numbering), but the results are different. OPENJPA-149 is concerned with being able to suspend a transaction. Some TranManagers allow for this, while others (like WebSphere) do not. But, WebSphere does provide a UOWSynchronizationRegistry which allows for "transaction suspend/resume" via a Runnable injection. Patrick would like to see this type of support more generalized in OpenJPA so that we could plug in other similar implementations. We have that on our plate. This Issue is related to what can or can not be set on a Shareable Connection once the associated transaction has started. For example, if you are sharing a connection with an isolation level of read-committed, you wouldn't want another application to change the isolation level out from under you in the middle of a transaction. So, WebSphere prevents operations like that from happening with shared connections. I'm surprised that other app servers don't act in the same manner, but to each their own. So, with this issue, we need to determine if the setting of isolation levels or auto commit or any other "non-shareable" property setting needs to be processed differently based on the environment. Thanks, Kevin
        Hide
        Craig L Russell added a comment -

        Is this issue the same as OPENJPA-149 perhaps? Trying to perform a non-transactional operation in Websphere?

        Show
        Craig L Russell added a comment - Is this issue the same as OPENJPA-149 perhaps? Trying to perform a non-transactional operation in Websphere?
        Hide
        Kevin Sutter added a comment -

        It sounds like WebSphere is working as expected. Since you are attempting to modify a Connection while a transaction is active, WebSphere is preventing the action. As you outlined, this would happen with setTransactionIsolation, setAutoCommit, and a few other settings that would compromise a shared connection.

        You could run with an Unshareable connection, but that's easier said than done since Shareable connections are the default when accessing via direct JNDI lookups.

        Another idea is to delay the starting of the transaction, but that may be application-specific. That is, you might be able to work around this situation in your given application, but that doesn't sound like a general purpose solution.

        What we might have to do is to use a JDBCConnectionSpec when attempting to get a Connection via the WSDataSource interface. This is very WebSphere specific, but I'm not sure what else we can do.

        I'm surprised that we haven't hit this type of problem with other application servers. Either the JNDI lookup is returning an Unshareable connection, or setting the isolation level on Shareable connections is allowed. Neither of these options is consistent with the expected behavior. Can anyone comment? I'm trying to figure out if we have a WebSphere-specific situation or a more genera problem.

        Kevin

        Show
        Kevin Sutter added a comment - It sounds like WebSphere is working as expected. Since you are attempting to modify a Connection while a transaction is active, WebSphere is preventing the action. As you outlined, this would happen with setTransactionIsolation, setAutoCommit, and a few other settings that would compromise a shared connection. You could run with an Unshareable connection, but that's easier said than done since Shareable connections are the default when accessing via direct JNDI lookups. Another idea is to delay the starting of the transaction, but that may be application-specific. That is, you might be able to work around this situation in your given application, but that doesn't sound like a general purpose solution. What we might have to do is to use a JDBCConnectionSpec when attempting to get a Connection via the WSDataSource interface. This is very WebSphere specific, but I'm not sure what else we can do. I'm surprised that we haven't hit this type of problem with other application servers. Either the JNDI lookup is returning an Unshareable connection, or setting the isolation level on Shareable connections is allowed. Neither of these options is consistent with the expected behavior. Can anyone comment? I'm trying to figure out if we have a WebSphere-specific situation or a more genera problem. Kevin
        Hide
        Kevin Sutter added a comment -

        From Ritikia (via dev mailing list)...

        Kevin,
        Yes it is JPA that is trying to set the isolation
        level.Thishappens when jpa is trying to get the next id from the
        sequence , at that
        point it tries to get the connection to database and it checks if the
        isolation level on the connection is READ_COMMITTED or not. And apparently
        the isolationLevel was not read committed therefore it tries to set it
        read-committed.I have specified the isolation level in my persistence.xml to
        read-committed.Following the code it appears taht AbstractJDBCSeq.next()
        finally calls

        protected RefCountConnection connectInternal() throws SQLException

        { *return* *new* RefCountConnection(_ds.getConnection()); }

        This is in JDBCStoreManager.The _ds.getConnection call will call

        public Connection decorate(Connection conn)

        throws SQLException

        { // some versions of the DB2 driver seem to default to // READ_UNCOMMITTED, which will prevent locking from working // (multiple SELECT ... FOR UPDATE statements are allowed on // the same instance); if we have not overridden the // transaction isolation in the configuration, default to // TRANSACTION_READ_COMMITTED conn = *super*.decorate(conn); *if* (conf.getTransactionIsolationConstant() == -1 && conn.getTransactionIsolation() < conn.*TRANSACTION_READ_COMMITTED*) conn.setTransactionIsolation(conn.*TRANSACTION_READ_COMMITTED*); *return* conn; }

        in DB2Dictionary and that is when it fails.This is what I suspect from
        looking at the code.It is tough to debug in zos websphere environment.But we
        have had previous issues where using zos type 2 driver in gloabal
        transaction we were getting errors that cannot setAutoCommit during gloabl
        transaction.So this has something to do with running in global
        transaction.Because I begin the transaction before I new up the
        entityManager.

        ritika

        Show
        Kevin Sutter added a comment - From Ritikia (via dev mailing list)... Kevin, Yes it is JPA that is trying to set the isolation level.Thishappens when jpa is trying to get the next id from the sequence , at that point it tries to get the connection to database and it checks if the isolation level on the connection is READ_COMMITTED or not. And apparently the isolationLevel was not read committed therefore it tries to set it read-committed.I have specified the isolation level in my persistence.xml to read-committed.Following the code it appears taht AbstractJDBCSeq.next() finally calls protected RefCountConnection connectInternal() throws SQLException { *return* *new* RefCountConnection(_ds.getConnection()); } This is in JDBCStoreManager.The _ds.getConnection call will call public Connection decorate(Connection conn) throws SQLException { // some versions of the DB2 driver seem to default to // READ_UNCOMMITTED, which will prevent locking from working // (multiple SELECT ... FOR UPDATE statements are allowed on // the same instance); if we have not overridden the // transaction isolation in the configuration, default to // TRANSACTION_READ_COMMITTED conn = *super*.decorate(conn); *if* (conf.getTransactionIsolationConstant() == -1 && conn.getTransactionIsolation() < conn.*TRANSACTION_READ_COMMITTED*) conn.setTransactionIsolation(conn.*TRANSACTION_READ_COMMITTED*); *return* conn; } in DB2Dictionary and that is when it fails.This is what I suspect from looking at the code.It is tough to debug in zos websphere environment.But we have had previous issues where using zos type 2 driver in gloabal transaction we were getting errors that cannot setAutoCommit during gloabl transaction.So this has something to do with running in global transaction.Because I begin the transaction before I new up the entityManager. ritika
        Hide
        Kevin Sutter added a comment -

        Ritika,
        The message you referenced...

        <0|true|0.9.6-incubating> org.apache.openjpa.persistence.PersistenceException: DSRA9250E: Operation setTransactionIsolation is not allowed during a global transaction for Shareable Connections.

        ... is coming from WebSphere. WebSphere supports the concept of shareable connections (per the JCA specification). Since these connections might be shared between applications, WebSphere doesn't want to surprise the user of a Shareable connection by allowing modification of properties that could affect the operation of that connection. In this case, somebody (OpenJPA?) is attempting to change the TransactionIsolation attribute of a Shareable connection while a global transaction is active. WebSphere prevents this as a safety net for our users. So, it looks like you need to understand why the transaction isolation is attempted to be set while the transaction is active. Either we need to hold off on changing the transaction isolation until the tran completes, or maybe the setting is superfluous (ie. the isolation level is not changing, but the invocation is happening regardless).

        Hope this helps.
        Kevin

        Show
        Kevin Sutter added a comment - Ritika, The message you referenced... <0|true|0.9.6-incubating> org.apache.openjpa.persistence.PersistenceException: DSRA9250E: Operation setTransactionIsolation is not allowed during a global transaction for Shareable Connections. ... is coming from WebSphere. WebSphere supports the concept of shareable connections (per the JCA specification). Since these connections might be shared between applications, WebSphere doesn't want to surprise the user of a Shareable connection by allowing modification of properties that could affect the operation of that connection. In this case, somebody (OpenJPA?) is attempting to change the TransactionIsolation attribute of a Shareable connection while a global transaction is active. WebSphere prevents this as a safety net for our users. So, it looks like you need to understand why the transaction isolation is attempted to be set while the transaction is active. Either we need to hold off on changing the transaction isolation until the tran completes, or maybe the setting is superfluous (ie. the isolation level is not changing, but the invocation is happening regardless). Hope this helps. Kevin
        Hide
        Patrick Linskey added a comment -

        0.9.6 is released; moving the fix version to 0.9.7 to reflect the best-case reality.

        Show
        Patrick Linskey added a comment - 0.9.6 is released; moving the fix version to 0.9.7 to reflect the best-case reality.

          People

          • Assignee:
            Albert Lee
            Reporter:
            Ritika Maheshwari
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development