[ http://issues.apache.org/jira/browse/IBATIS-318?page=comments#action_12420455 ]
adamb commented on IBATIS-318: ------------------------------ Cheers. We are using iBATIS as the implementation of an API that requires long running transactions (i.e. a server call is not an atomic action)... This is within an automated conversion framework, so switching to atomic transactions is not an option for us. We want to keep our framework using iBATIS because we believe that it is ideal for any future work that gets done after the conversion, but it must be able to support both modes. Our other competing option is to create a JDBC implementation of the API. > Transaction demarcated accross multiple threads... > -------------------------------------------------- > > Key: IBATIS-318 > URL: http://issues.apache.org/jira/browse/IBATIS-318 > Project: iBatis for Java > Type: Bug > Components: SQL Maps > Versions: 2.1.5 > Reporter: adamb > > We are using iBATIS in the following way: > send the server a message which will do a SqlMap.startTransaction() > ... > some time later > ... > send the server a message which will do a SqlMap.<some sql operation> > ... > If we set: > Pool.MaximumActiveConnections=1 > Then we hit problems if the thread that does operations on the SqlMap is > different to the thread which started the transaction > because > SqlMapClientImpl.getLocalSqlMapSession() > stores the session in a Threadlocal so it finds no session and attempts to > automatically create a new one, but since the max connections has been > reached it fails. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
