Hi all,<br><br>We have an transaction error that has recently appeared consistently:  a stateful session bean (SFSB) has an application error and throws an exception. The next time the application tries to use the stateful session bean it gets an error:<br>
<br>tried to enter
Stateful bean with different tx context, <br>contextTx: TransactionImple
<br>      &lt; ac, BasicAction: a640128:983:4af49b0f:299 status:
ActionStatus.RUNNING &gt;, <br>methodTx: TransactionImple<br>     &lt; ac,
BasicAction: a640128:983:4af49b0f:348 status: ActionStatus.RUNNING &gt;<br>
<br>Revewing the ejb literature, I see that if the SFSB throws a SystemException (eg. EJBException) w, cause the app server will discard the SFSB instance. Currently the SFSB throws an application exception. This seems like a straightforward fix.<br>
<br>This code has been in place for a few years, and we&#39;ve been running jboss 4.2. for a few years. So we&#39;re a bit puzzled &quot;why now?&quot;  <br><br>One change: we have recently upgraded the jdbc drivers (mssql) from to microsoft&#39;s version 1.1 to  2.0. The 1.2-and-later-driver handles transaction-id&#39;s-in-the-jdbc-connection differently than the earlier 1.1 drivers. (The jdbc connection implementation actually keeps a reference to the current transaction id in the database. After we upgraded the driver, we saw another problem where bad exception handling kept a stale &#39;mssql transaction id&#39; around in the jdbc connection. Properly closing the result set/stmt/connection upon error solved this jdbc transaction-id-hanging-around problem). <br>
<br>After reviewing the jboss 4.2.3 code, however, I suspect that the &#39;jdbc driver version&#39; change may in not in fact pertain at all to our stateful session bean problem, i.e. it&#39;s a &#39;red herring&#39;,.  The arjuna/user-transaction/statefulsession code does not even touch the jdbc driver.  Unless I missed something<br>
<br>So a few follow-in questions. Can anyone comment/weigh-in/opine/pontificate:<br>* whether they&#39;ve seen this issue?<br>* throwing EJBException&#39;s will solve this problem<br>* comment<br>* any tips for debugging solving these types of problems?<br>
<br>thanks,<br><br>bill<br><br>