[JCA/JBoss] - Possible failure to cleanup connection when returned to pool
by tapina
Hi
Wasn't sure whether to post to JIRA but decided best to check on the forums first. Sorry it's a bit woolly but it's an intermittent fault and I'm not that familiar with the JBoss connection wrapper classes. Just for extra fun, it only seems to happen for us under production load.
I've recently been seeing some occasional errors from our Oracle datasource to do with being unable to SET TRANSACTION due to the current connection state being inappropriate (ORA-01453 locally and ORA-02070 on database links). These errors originate when not explicitly setting transaction (e.g. executing a query, or closing a connection when JBoss tries to reset the transaction). These are on no-tx-connections (i.e. unmanaged).
My suspicion is that the current transaction is not "finished" as far as Oracle is concerned when the JBoss wrappers try to change it, and I know it's picky about this. Because connections don't really get closed, our Java code has to be meticulous about closing statements and result sets (if autocommit is on) and committing and rolling back when its off. However, this is a huge legacy app recently migrated to JBoss and I'm sure there are areas where it fails to clean up properly.
This is where I'd hope the pool comes in, cleaning up connections before reissuing them to another unsuspecting thread. JBoss makes an attempt to clean up by setting autocommit on closure: I think there's a case where the JBoss pools don't clean up properly but I can't be sure.
We use the connections from the pool in both autocommit and non-autocommit modes in different parts of the code. The JBoss wrapped connections only apply this flag at the point where another operation is carried out on the connection (if the flag has changed). This is what I think might be happening:
1. One bit of our code gets a nice fresh connection from the pool using JNDI.
2. The connection is set to autocommit FALSE.
3. We fail to clean up properly after ourselves. Oracle's transaction state is not reset.
4. We close the connection and JBoss sets the autocommit flag TRUE in BaseWrapperManagedConnection.cleanup(), but crucially does not apply this to the underlying connection yet.
5. Another bit of our code gets the reused connection.
6. We set it to autocommit FALSE. Note that this does not get applied to the underlying connection at all because it matches the current state of the underlying connection already and the previous change was never applied.
7. At some later point the transaction level is changed, but there has been no reset of Oracle's transaction status so it complains.
I have tried to mitigate this by making sure to setAutoCommit(false), rollback() and then setAutoCommit(true) if required EVERY TIME I fetch a connection with JNDI. I will see what success this has.
Would be interested in any suggested fixes, workarounds, ideas etc. Is this a bug? I think only Oracle is as picky about the transaction state as this, and the root cause really is most likely to be our failure to clean up properly ourselves - but shouldn't the pool make sure this doesn't trip up unrelated areas of the app?
Regards
Gareth
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234702#4234702
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234702
16 years, 10 months
[JBossWS] - Call WebService in EJB 3.0 (Differences to EJB 2.1)
by bjoern83
Hi,
I had an EJB 2.1 Bean containing a WebService-Method:
/** @jboss.port-component name="WebServiceControllerService" uri="/VERSION-ejb/WebServiceController"
| * auth-method="BASIC" transport-guarantee="NONE"
| * @ejb.bean name="WebServiceController" display-name="WebServiceController" generate="true"
| * jndi-name="ejb/WebServiceController" local-jndi-name="ejb/WebServiceControllerLocal"
| * view-type="all" type="Stateless"
| *
| * @ejb.home generate="local,remote"
| *
| * @ejb.interface generate="local,remote,service-endpoint"
| * remote-class="de.cursor.jevi.server.web.WebServiceController"
| * local-class="de.cursor.jevi.server.web.WebServiceControllerLocal"
| * service-endpoint-class="de.cursor.jevi.server.web.WebServiceControllerService"
| */
| public class WebServiceControllerBean implements SessionBean
| {
| public String search(String xmlSearch)
| {
| }
| }
I called this method using SOAPUI with the following URI:
http://Nebelos-C2Q:18080/CARMEN-ejb/WebServiceController
which is "MyServer" + "MyJar" + "MyWebServiceClassRemoteInterface".
Now I migrated my class to EJB 3.0:
@Stateless(name = "ejbWebServiceController")
| @TransactionManagement(TransactionManagementType.CONTAINER)
| @TransactionAttribute(TransactionAttributeType.SUPPORTS)
| @PermitAll
| @WebService
| @SOAPBinding(style = SOAPBinding.Style.RPC)
| @SecurityDomain(value = "VERSION")
| @Clustered(loadBalancePolicy = de.cursor.jboss.cluster.JBossLoadBalancer.class, partition = "DefaultPartition")
| public class WebServiceControllerBean implements WebServiceControllerLocal, WebServiceController
| {
| @WebMethod(operationName = "search")
| public String search(String xmlSearch)
| {
| }
| }
My SOAP-UI call doesn't work any more telling me "The requested resource (/CARMEN-ejb/WebServiceController) is not available.". Can somebody tell me how the new uri would be or (better) how to get the old one?
thanking you in anticipation
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234688#4234688
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234688
16 years, 10 months