Topic
  • 5 replies
  • Latest Post - ‏2006-08-24T19:18:48Z by SystemAdmin
SystemAdmin
SystemAdmin
37421 Posts

Pinned topic Websphere 6.1 Suspended Transaction

‏2006-08-23T04:46:45Z |
Hi all,

I am trying to declare a CMT on a SSB method via deployment descriptor as RequiresNew, which at runtime exists within the context of an existing transaction (another CMT).

Given this, when an exception is thrown within outer txn scope (intentional for POC rollback) after the inner (RequiresNew) txn has comitted via CMT, the inner txn commit should be reflected within the underlying database and the outer txn rollback should not. This is not the case however as neither updates appear in the database, implying that the inner txn is rolled back as well.

I have posted on the spring forum at http://forum.springframework.org/showthread.php?t=28321 which describes the problem from a spring/hibernate configuration perspective, but basically what I noticed when tracing through the layers of Springs' JTA transaction manager wrapping was that there is no TransactionManagerFactory for websphere 6.1 - it is still using the 5.1 factory. Is this correct or should there now be a 6.1 factory to handle this situation?

The Spring javadoc state that plugging in a vendor-specific JTA manager to the default Spring JTA txn manager should be enough to get suspended transactions working, so If the above is not the problem is there another configuration step I should be performing within a websphere context?

Likewise are there any known issues surrounding transactions in Websphere 6.1? I could not find any in the provided documentation on the ibm website.

Thanks in advance,
Damian Phillips
Library Context
Spring 2.0-rc2
Hibernate 3.2.0.cr2
Updated on 2006-08-24T19:18:48Z at 2006-08-24T19:18:48Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    37421 Posts

    Re: Websphere 6.1 Suspended Transaction

    ‏2006-08-23T12:55:24Z  
    Spring suspended transactions are not supported within WebSphere. In
    that case, Spring attempts to control transactions by directly invoking
    WebSphere's internal TransactionManager implementation, which was not
    intended for use by outside code. This causes the server to go into an
    inconsistent transactional state. That is why your SSB method is not
    giving correct behavior with respect to transactions; the EJB container
    hosting your SSB is not aware that Spring changed the transactional
    state, since Spring used the TransactionManager interface rather than
    the standard UserTransaction interface.

    Spring is only allowed to use the standard UserTransaction interface;
    this interface correctly maintains transactional state within the
    server. (This interface is what the default Spring JTA txn manager
    uses.) The problem arises because Spring is attempting to use more than
    the standard UserTransaction interface in the vendor-specific JTA txn
    manager.

    It is not completely clear how the code in the WebSphere-specific Spring
    JTA txn manager was developed, but it apparently uses internal private
    WAS APIs that have never been externally published, and which are not
    supported for use by external applications. WebSphere does not make the
    TransactionManager interface available to external code.

    Damian.Phillips@dse.vic.gov.au wrote:
    > Hi all,
    >
    > I am trying to declare a CMT on a SSB method via deployment descriptor as RequiresNew, which at runtime exists within the context of an existing transaction (another CMT).
    >
    > Given this, when an exception is thrown within outer txn scope (intentional for POC rollback) after the inner (RequiresNew) txn has comitted via CMT, the inner txn commit should be reflected within the underlying database and the outer txn rollback should not. This is not the case however as neither updates appear in the database, implying that the inner txn is rolled back as well.
    >
    > I have posted on the spring forum at http://forum.springframework.org/showthread.php?t=28321 which describes the problem from a spring/hibernate configuration perspective, but basically what I noticed when tracing through the layers of Springs' JTA transaction manager wrapping was that there is no TransactionManagerFactory for websphere 6.1 - it is still using the 5.1 factory. Is this correct or should there now be a 6.1 factory to handle this situation?
    >
    > The Spring javadoc state that plugging in a vendor-specific JTA manager to the default Spring JTA txn manager should be enough to get suspended transactions working, so If the above is not the problem is there another configuration step I should be performing within a websphere context?
    >
    > Likewise are there any known issues surrounding transactions in Websphere 6.1? I could not find any in the provided documentation on the ibm website.
    >
    > Thanks in advance,
    > Damian Phillips
    >
    >
    > Library Context
    > Spring 2.0-rc2
    > Hibernate 3.2.0.cr2
  • SystemAdmin
    SystemAdmin
    37421 Posts

    Re: Websphere 6.1 Suspended Transaction

    ‏2006-08-23T13:06:24Z  
    Spring suspended transactions are not supported within WebSphere. In
    that case, Spring attempts to control transactions by directly invoking
    WebSphere's internal TransactionManager implementation, which was not
    intended for use by outside code. This causes the server to go into an
    inconsistent transactional state. That is why your SSB method is not
    giving correct behavior with respect to transactions; the EJB container
    hosting your SSB is not aware that Spring changed the transactional
    state, since Spring used the TransactionManager interface rather than
    the standard UserTransaction interface.

    Spring is only allowed to use the standard UserTransaction interface;
    this interface correctly maintains transactional state within the
    server. (This interface is what the default Spring JTA txn manager
    uses.) The problem arises because Spring is attempting to use more than
    the standard UserTransaction interface in the vendor-specific JTA txn
    manager.

    It is not completely clear how the code in the WebSphere-specific Spring
    JTA txn manager was developed, but it apparently uses internal private
    WAS APIs that have never been externally published, and which are not
    supported for use by external applications. WebSphere does not make the
    TransactionManager interface available to external code.

    Damian.Phillips@dse.vic.gov.au wrote:
    > Hi all,
    >
    > I am trying to declare a CMT on a SSB method via deployment descriptor as RequiresNew, which at runtime exists within the context of an existing transaction (another CMT).
    >
    > Given this, when an exception is thrown within outer txn scope (intentional for POC rollback) after the inner (RequiresNew) txn has comitted via CMT, the inner txn commit should be reflected within the underlying database and the outer txn rollback should not. This is not the case however as neither updates appear in the database, implying that the inner txn is rolled back as well.
    >
    > I have posted on the spring forum at http://forum.springframework.org/showthread.php?t=28321 which describes the problem from a spring/hibernate configuration perspective, but basically what I noticed when tracing through the layers of Springs' JTA transaction manager wrapping was that there is no TransactionManagerFactory for websphere 6.1 - it is still using the 5.1 factory. Is this correct or should there now be a 6.1 factory to handle this situation?
    >
    > The Spring javadoc state that plugging in a vendor-specific JTA manager to the default Spring JTA txn manager should be enough to get suspended transactions working, so If the above is not the problem is there another configuration step I should be performing within a websphere context?
    >
    > Likewise are there any known issues surrounding transactions in Websphere 6.1? I could not find any in the provided documentation on the ibm website.
    >
    > Thanks in advance,
    > Damian Phillips
    >
    >
    > Library Context
    > Spring 2.0-rc2
    > Hibernate 3.2.0.cr2
    > Damian.Phillips@dse.vic.gov.au wrote:
    >> Hi all,
    >>
    >> I am trying to declare a CMT on a SSB method via deployment
    >> descriptor as RequiresNew, which at runtime exists within the
    >> context of an existing transaction (another CMT).
    >>
    >> Given this, when an exception is thrown within outer txn scope
    >> (intentional for POC rollback) after the inner (RequiresNew) txn
    >> has comitted via CMT, the inner txn commit should be reflected
    >> within the underlying database and the outer txn rollback should
    >> not. This is not the case however as neither updates appear in the
    >> database, implying that the inner txn is rolled back as well.

    Randy Schnier wrote:
    > Spring suspended transactions are not supported within WebSphere. In
    > that case, Spring attempts to control transactions by directly
    > invoking WebSphere's internal TransactionManager implementation,
    > which was not intended for use by outside code. This causes the
    > server to go into an inconsistent transactional state. That is why
    > your SSB method is not giving correct behavior with respect to
    > transactions; the EJB container hosting your SSB is not aware that
    > Spring changed the transactional state, since Spring used the
    > TransactionManager interface rather than the standard UserTransaction
    > interface.

    >
    I would also note that what you are trying to achieve is trivial if you
    just use EJBs and not Spring (or at least don't use any of Spring's
    transaction management "features").
  • SystemAdmin
    SystemAdmin
    37421 Posts

    Re: Websphere 6.1 Suspended Transaction

    ‏2006-08-24T06:34:21Z  
    Spring suspended transactions are not supported within WebSphere. In
    that case, Spring attempts to control transactions by directly invoking
    WebSphere's internal TransactionManager implementation, which was not
    intended for use by outside code. This causes the server to go into an
    inconsistent transactional state. That is why your SSB method is not
    giving correct behavior with respect to transactions; the EJB container
    hosting your SSB is not aware that Spring changed the transactional
    state, since Spring used the TransactionManager interface rather than
    the standard UserTransaction interface.

    Spring is only allowed to use the standard UserTransaction interface;
    this interface correctly maintains transactional state within the
    server. (This interface is what the default Spring JTA txn manager
    uses.) The problem arises because Spring is attempting to use more than
    the standard UserTransaction interface in the vendor-specific JTA txn
    manager.

    It is not completely clear how the code in the WebSphere-specific Spring
    JTA txn manager was developed, but it apparently uses internal private
    WAS APIs that have never been externally published, and which are not
    supported for use by external applications. WebSphere does not make the
    TransactionManager interface available to external code.

    Damian.Phillips@dse.vic.gov.au wrote:
    > Hi all,
    >
    > I am trying to declare a CMT on a SSB method via deployment descriptor as RequiresNew, which at runtime exists within the context of an existing transaction (another CMT).
    >
    > Given this, when an exception is thrown within outer txn scope (intentional for POC rollback) after the inner (RequiresNew) txn has comitted via CMT, the inner txn commit should be reflected within the underlying database and the outer txn rollback should not. This is not the case however as neither updates appear in the database, implying that the inner txn is rolled back as well.
    >
    > I have posted on the spring forum at http://forum.springframework.org/showthread.php?t=28321 which describes the problem from a spring/hibernate configuration perspective, but basically what I noticed when tracing through the layers of Springs' JTA transaction manager wrapping was that there is no TransactionManagerFactory for websphere 6.1 - it is still using the 5.1 factory. Is this correct or should there now be a 6.1 factory to handle this situation?
    >
    > The Spring javadoc state that plugging in a vendor-specific JTA manager to the default Spring JTA txn manager should be enough to get suspended transactions working, so If the above is not the problem is there another configuration step I should be performing within a websphere context?
    >
    > Likewise are there any known issues surrounding transactions in Websphere 6.1? I could not find any in the provided documentation on the ibm website.
    >
    > Thanks in advance,
    > Damian Phillips
    >
    >
    > Library Context
    > Spring 2.0-rc2
    > Hibernate 3.2.0.cr2
    Randy,

    Thanks for the prompt response!
    I have performed some more investigations from you reply and can confirm some more details.

    I have updated our config to the most simplistic JTA config I can see, so I am now directly configuring all JTA management to hibernate (bypassing spring JTA config). My updated spring application context hibernate is below.

    I have remotely debugged my way through this and identified the problem as the inner txn is never comitted independently - the db is not updated until the outer txn commits, hence the container seems to be basically ignoring it when it should be committing. Conversely, if I change the inner txn type (CMT) in the deployment descriptor to NEVER the correct exception is thrown by the container stating this txn cannot exist within a global txn - so the container is trying to begin a new (inner) transaction at the correct location.

    I have similarly looked into the WebSphereTransactionManagerLookup source and have noticed that likewise there is no specific TransactionManagerFactory class specified for Websphere 6.1, rather just versions 4, 5, and 5.1 as was the case for Spring. Should the WebSphereTransactionManagerLookup be referencing a newer TransactionManagerFactory for WS6.1, or will the 5.1 version (which is being returned) suffice?
    Thanks in advance,
    Damian Phillips

    Spring ApplicationContext
    <bean id="mySessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
    <property name="dataSource" ref="ecDataSource" />
    <property name="configLocation" value="classpath:resource/hibernate.cfg.xml" />
    <property name="lobHandler" ref="myLobHandler" />
    <property name="hibernateProperties">
    <props>
    <!-- Database Settings -->
    <prop key="hibernate.default_schema">alex</prop>
    <prop key="hibernate.dialect">org.hibernate.dialect.Oracle9Dialect</prop>
    <prop key="hibernate.show_sql">true</prop>
    <prop key="hibernate.bytecode.use_reflection_optimizer">false</prop>

    <!-- JDBC Settings -->
    <prop key="hibernate.jdbc.use_streams_for_binary">true</prop>
    <prop key="hibernate.max_fetch_depth">1</prop>

    <!-- Cache settings -->
    <prop key="hibernate.cache.provider_class">org.hibernate.cache.HashtableCacheProvider</prop>

    <!-- Transaction Support -->
    <prop key="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.WebSphereTransactionManagerLookup</prop>
    <prop key="hibernate.transaction.factory_class">org.hibernate.transaction.CMTTransactionFactory</prop>
    <prop key="hibernate.current_session_context_class">jta</prop>
    <prop key="transaction.auto_close_session">true</prop>
    <prop key="transaction.flush_before_completion">true</prop>
    </props>
    </property>
    </bean>
    <bean id="ecDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="java:comp/env/jdbc/lx" />
    </bean>

    <bean id="myNativeJdbcExtractor" class="org.springframework.jdbc.support.nativejdbc.WebSphereNativeJdbcExtractor" />

    <bean id="myHibernateInterceptor" class="org.springframework.orm.hibernate3.HibernateInterceptor">
    <property name="sessionFactory" ref="mySessionFactory" />
    </bean>

  • SystemAdmin
    SystemAdmin
    37421 Posts

    Re: Websphere 6.1 Suspended Transaction

    ‏2006-08-24T18:46:27Z  
    Randy,

    Thanks for the prompt response!
    I have performed some more investigations from you reply and can confirm some more details.

    I have updated our config to the most simplistic JTA config I can see, so I am now directly configuring all JTA management to hibernate (bypassing spring JTA config). My updated spring application context hibernate is below.

    I have remotely debugged my way through this and identified the problem as the inner txn is never comitted independently - the db is not updated until the outer txn commits, hence the container seems to be basically ignoring it when it should be committing. Conversely, if I change the inner txn type (CMT) in the deployment descriptor to NEVER the correct exception is thrown by the container stating this txn cannot exist within a global txn - so the container is trying to begin a new (inner) transaction at the correct location.

    I have similarly looked into the WebSphereTransactionManagerLookup source and have noticed that likewise there is no specific TransactionManagerFactory class specified for Websphere 6.1, rather just versions 4, 5, and 5.1 as was the case for Spring. Should the WebSphereTransactionManagerLookup be referencing a newer TransactionManagerFactory for WS6.1, or will the 5.1 version (which is being returned) suffice?
    Thanks in advance,
    Damian Phillips

    Spring ApplicationContext
    <bean id="mySessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
    <property name="dataSource" ref="ecDataSource" />
    <property name="configLocation" value="classpath:resource/hibernate.cfg.xml" />
    <property name="lobHandler" ref="myLobHandler" />
    <property name="hibernateProperties">
    <props>
    <!-- Database Settings -->
    <prop key="hibernate.default_schema">alex</prop>
    <prop key="hibernate.dialect">org.hibernate.dialect.Oracle9Dialect</prop>
    <prop key="hibernate.show_sql">true</prop>
    <prop key="hibernate.bytecode.use_reflection_optimizer">false</prop>

    <!-- JDBC Settings -->
    <prop key="hibernate.jdbc.use_streams_for_binary">true</prop>
    <prop key="hibernate.max_fetch_depth">1</prop>

    <!-- Cache settings -->
    <prop key="hibernate.cache.provider_class">org.hibernate.cache.HashtableCacheProvider</prop>

    <!-- Transaction Support -->
    <prop key="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.WebSphereTransactionManagerLookup</prop>
    <prop key="hibernate.transaction.factory_class">org.hibernate.transaction.CMTTransactionFactory</prop>
    <prop key="hibernate.current_session_context_class">jta</prop>
    <prop key="transaction.auto_close_session">true</prop>
    <prop key="transaction.flush_before_completion">true</prop>
    </props>
    </property>
    </bean>
    <bean id="ecDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="java:comp/env/jdbc/lx" />
    </bean>

    <bean id="myNativeJdbcExtractor" class="org.springframework.jdbc.support.nativejdbc.WebSphereNativeJdbcExtractor" />

    <bean id="myHibernateInterceptor" class="org.springframework.orm.hibernate3.HibernateInterceptor">
    <property name="sessionFactory" ref="mySessionFactory" />
    </bean>

    Damian,

    Spring should not be referencing any WebSphere
    TransactionManagerFactory classes. No version of WebSphere has ever
    made the TransactionManager interface available to external code.

    In essence, the WebSphereTransactionManagerLookup class should not
    exist. WebSphere doesn't provide a TransactionManager to look up in the
    first place.

    Damian.Phillips@dse.vic.gov.au wrote:
    >
    >
    > I have similarly looked into the WebSphereTransactionManagerLookup source and have noticed that likewise there is no specific TransactionManagerFactory class specified for Websphere 6.1, rather just versions 4, 5, and 5.1 as was the case for Spring. Should the WebSphereTransactionManagerLookup be referencing a newer TransactionManagerFactory for WS6.1, or will the 5.1 version (which is being returned) suffice?
    >
    >
    > Thanks in advance,
    > Damian Phillips
    >
  • SystemAdmin
    SystemAdmin
    37421 Posts

    Re: Websphere 6.1 Suspended Transaction

    ‏2006-08-24T19:18:48Z  
    Randy,

    Thanks for the prompt response!
    I have performed some more investigations from you reply and can confirm some more details.

    I have updated our config to the most simplistic JTA config I can see, so I am now directly configuring all JTA management to hibernate (bypassing spring JTA config). My updated spring application context hibernate is below.

    I have remotely debugged my way through this and identified the problem as the inner txn is never comitted independently - the db is not updated until the outer txn commits, hence the container seems to be basically ignoring it when it should be committing. Conversely, if I change the inner txn type (CMT) in the deployment descriptor to NEVER the correct exception is thrown by the container stating this txn cannot exist within a global txn - so the container is trying to begin a new (inner) transaction at the correct location.

    I have similarly looked into the WebSphereTransactionManagerLookup source and have noticed that likewise there is no specific TransactionManagerFactory class specified for Websphere 6.1, rather just versions 4, 5, and 5.1 as was the case for Spring. Should the WebSphereTransactionManagerLookup be referencing a newer TransactionManagerFactory for WS6.1, or will the 5.1 version (which is being returned) suffice?
    Thanks in advance,
    Damian Phillips

    Spring ApplicationContext
    <bean id="mySessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
    <property name="dataSource" ref="ecDataSource" />
    <property name="configLocation" value="classpath:resource/hibernate.cfg.xml" />
    <property name="lobHandler" ref="myLobHandler" />
    <property name="hibernateProperties">
    <props>
    <!-- Database Settings -->
    <prop key="hibernate.default_schema">alex</prop>
    <prop key="hibernate.dialect">org.hibernate.dialect.Oracle9Dialect</prop>
    <prop key="hibernate.show_sql">true</prop>
    <prop key="hibernate.bytecode.use_reflection_optimizer">false</prop>

    <!-- JDBC Settings -->
    <prop key="hibernate.jdbc.use_streams_for_binary">true</prop>
    <prop key="hibernate.max_fetch_depth">1</prop>

    <!-- Cache settings -->
    <prop key="hibernate.cache.provider_class">org.hibernate.cache.HashtableCacheProvider</prop>

    <!-- Transaction Support -->
    <prop key="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.WebSphereTransactionManagerLookup</prop>
    <prop key="hibernate.transaction.factory_class">org.hibernate.transaction.CMTTransactionFactory</prop>
    <prop key="hibernate.current_session_context_class">jta</prop>
    <prop key="transaction.auto_close_session">true</prop>
    <prop key="transaction.flush_before_completion">true</prop>
    </props>
    </property>
    </bean>
    <bean id="ecDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="java:comp/env/jdbc/lx" />
    </bean>

    <bean id="myNativeJdbcExtractor" class="org.springframework.jdbc.support.nativejdbc.WebSphereNativeJdbcExtractor" />

    <bean id="myHibernateInterceptor" class="org.springframework.orm.hibernate3.HibernateInterceptor">
    <property name="sessionFactory" ref="mySessionFactory" />
    </bean>

    Damian.Phillips@dse.vic.gov.au wrote:
    > Randy,
    >
    > Thanks for the prompt response! I have performed some more
    > investigations from you reply and can confirm some more details.
    >
    > I have updated our config to the most simplistic JTA config I can
    > see, so I am now directly configuring all JTA management to hibernate
    > (bypassing spring JTA config). My updated spring application context
    > hibernate is below.

    Is hibernate using WAS connection pools? If so, and if your beans are
    CMT, it should just work, without needing to do any of this TM
    configuration. It seems like you are making it far harder than it ought
    to be ...