ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim_Ham...@mcnichols.com
Subject Re: websphere ejb transaction rollback and SQL Stored Procedure
Date Wed, 02 Mar 2005 22:59:37 GMT

Thanks for your suggestion.  I threw together a simple factory dishing out 
non-iBatis Daos and kept SqlMaps as is (not changing its configuration at 
all - still External and using the settings necessary for WebSphere).  The 
problem remains.  I have a pmr open with IBM related to this issue - I 
suppose I will proceed along those lines.  As stated previously, my only 
workaround at this time is to change from SQL stored procedures to java 
stored procedures (correction from earlier post - I do not have to call 
setAutoCommit(false)).  This solves the problem allowing for a complete 
transaction rollback.  It seems that the use of the SQL stored procedure 
always uses a new connection?  Whereas, in the java stored procedure the 
connection is obtained using the following code which apparently correctly 
honors the original connection:

Connection con = DriverManager.getConnection("jdbc:default:connection");

 BTW, we are experiencing other DB2 UDB for iSeries related lock space 
issues - kind of a mess right now.  I think that our combination of 
WebSphere and DB2 UDB for iSeries makes for a pretty shaky environment.


Clinton Begin <clinton.begin@gmail.com> 
02/26/2005 11:11 PM
Please respond to


Re: websphere ejb transaction rollback and SQL Stored Procedure


Although I can't pinpoint the exact problem, I would suggest you NOT
use iBATIS DAO in your particular case.  It's simply too many
transaction managers.  All you really need is a factory for your DAOs.
 Your transactions are controlled by the container and the SQL and
JDBC is handled by iBATIS.  Your DAO needs are simple enough that you
might as well just use your own factory.

If you agree, and make the change, then let us know if the problem 


On Mon, 21 Feb 2005 15:27:15 -0500, Tim_Hammar@mcnichols.com
<Tim_Hammar@mcnichols.com> wrote:
> Greetings, 
> I am having quite peculiar behavior in the area of transaction rollback. 
> I am calling a setRollbackOnly() from an EJB stateless session bean. The
> rollback is only partially successful - updates from "plain" update 
> roll back successfully, updates from SQL stored procedures do not.  It 
> as if autocommit is in the picture for the SPs but not for the queries. 
> have rewritten one of them as a java stored procedure and added a
> setAutoCommit(false) method call.  This allows proper transaction 
> behavior.  There are definitely no commits in the stored procedures. Per
> IBM, I have confirmed my set up of a Web resource pointing to a jndi 
> source with a transaction isolation level of read-uncommitted. 
> Stepping through the iBatis source code, I see commits still being 
> but assume they are ignored since with EJB container managed 
> there should be a Global transaction controlling things, right? 
>  I hate the thought of rewriting all of the SPs as java stored 
> (there are many) where I seem to have some control over autocommit. 
> I realize that this is probably an IBM issue, but any help would be 
> appreciated. 
> The environment: 
> Using both SqlMap and DAO products 
> Websphere 5.1 
> db2 udb for iSeries 
> ejb stateless session bean controlling transaction consisting of: 
>     - SQL stored procedure performing an insert 
>     - other table updates via queries 
> web datasource resource reference specifying 
> isolation level 
> jdbc driver = jtopen 4.6  ( com.ibm.as400.access.AS400JDBCXADataSource ) 

> My iBatis setup (based upon the wiki's Websphere suggestions): 
> sqlmap config: 
> <transactionManager commitRequired="true" type="EXTERNAL" > 
>             <property name="DefaultAutoCommit" value="false" /> 
>         <property name="SetAutoCommitAllowed" value="false" /> 
>       <dataSource type="JNDI"> 
>                <property name="DataSource" value="${DBSOURCE}"/> 
>         </dataSource> 
> </transactionManager> 
> daoconfig: 
> <daoConfig> 
>   <!--  Common SQLMAP context (app start-up, etc. --> 
>   <context> 
>     <transactionManager type="SQLMAP"> 
>       <property name="SqlMapConfigResource" 
>     </transactionManager> 
>     <dao 
>   </context> 
> </daoConfig> 
> Regards, 
> Tim 

View raw message