dcsimg
Transacted DataSources, jConnect5.5, Weblogic 6.1: encountering "SET CHAINED command not allowed ..." exception when using transacted datasources.
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Anonymous
Posted On:   Thursday, January 16, 2003 05:36 AM

Our application uses the Sybase jConnect 5.5 API going against an Sybase 11.9 server. We have a large group of EJBs who's methods are deployed as transaction Required. We have used the standard EJB business facade design pattern to provide a single point of entry for our top level business processes. In order to have the database connections opened by these EJBs all running under the container managed transaction the connections needs to be created from a Transacted DataSource . When we configure a transacted datasource we find that the connection works correctly across multiple requests until the an exception is thrown somewhere along the callpath. On all subsequent requests/transacations that use this connection we get the following ex   More>>

Our application uses the Sybase jConnect 5.5 API going against an Sybase 11.9 server. We have a large group of EJBs who's methods are deployed as transaction Required. We have used the standard EJB business facade design pattern to provide a single point of entry for our top level business processes. In order to have the database connections opened by these EJBs all running under the container managed transaction the connections needs to be created from a Transacted DataSource . When we configure a transacted datasource we find that the connection works correctly across multiple requests until the an exception is thrown somewhere along the callpath. On all subsequent requests/transacations that use this connection we get the following exception:



SET CHAINED command not allowed within multi-statement transaction.



You can reproduce this error in isql by executing "SET CHAINED ON" a second time before committing your transaction.



I also see this error at random points even when an exception hasnt been thrown, but throwing an exception is a sure way to cause this issue.



To clarify:



(i) we call one of the top level business methods, container creates a transaction, multiple EJB's are called, multiple connections are used, transaction commits successfully, all is good



(ii) repeate step (i) as many times as you want, they all work, no exceptions are encountered.



(iii) as soon as something in step (i) throws an exception, all subsequent attempts to retrieve a transacted data source will result in the above exception.



In the code that we are using to debug this, the callpath involves 4 EJBs, one is the top level business interface (stateless session), the other three are BMP entity beans each responsible for creating an entry in a different table. I've done the following in trying to track down this bug



(a) ensured that all connections are closed in finally blocks . Monitoring the number of connections via the weblogic console shows us that the connections are being closed correctly.



(b) we called Connection.commit() in all cases where the database activity has been successful and Connection.rollback() otherwise (even though calling commit or rollback within container managed transactions is counter the EJB specification). All of the values that are inserted by each of the beans can be seen in the respective tables at the end of the method invocation.



(b) ensured that when exceptions get thrown that everything along the call path catches the exception and calls EJBContext.setRollbackOnly() . I have hard coded the throwing of exceptions at different points in the callpath. When the exception is thrown, all entries in all tables are rolledback, this shows us that there is an overriding transaction being managed by the application server and that it is being rolled back when setRollbackOnly is called.



(c) we removed the calls to Connection.commit() and rollback() and only used EJBContext.setRollbackOnly() letting the container do all of the connection management (as per the spec).



We are not calling setAutoCommit(false)



Currently, weblogic is configured with one connection pool and two datasources. One of the datasources is transacted, one of them is not. Each of these datasources (the transacted and the non-transacted) both use the same connection pool. I didnt find anything in the documentation that said that this couldnt be done but just to be safe I tried creating two connection pools, one for each of the datasources, this didnt make any difference.




Has anybody seen this before? What is it about weblogic's transacted datasource that causes this error?



Thanks for your help.



Cortez.

   <<Less

Re: Transacted DataSources, jConnect5.5, Weblogic 6.1: encountering "SET CHAINED command not allowed ..." exception when using transacted datasources.

Posted By:   Anonymous  
Posted On:   Friday, January 17, 2003 12:34 AM

How is this connected to the JUnit testing framework???
About | Sitemap | Contact