Sounds more like we need to provide savepoints support for this kind of stuff. Nested Transactions sound yucky.
Brandon On 6/3/05, Niels Beekman <[EMAIL PROTECTED]> wrote: > Yes, but they are not separate, I think the following happens: > > MyDao > getObject() > startTransaction() > MyTypeHandlerCallBack.getResult() > MyOtherDao.getOtherObject() > startTransaction() - state is already active, > continue > // process OtherObject > commitTransaction() - commits the transaction > endTransaction() - closes the resultset / > statement > GetSomeMoreProperties() - throws an exception, > resultset is already closed > commitTransaction() > endTransaction() > > All calls to a DAO are wrapped in a DaoProxy which takes care of the > autocommit-behaviour, if you call a DAO within a DAO (via typehandlers), > commitTransaction() is called on the DaoContext, which is the same for both > DAO's. > > To make this work properly, autocommit should happen on separate contexts, or > commitTransaction() should implement some kind of "transaction-depth" i.e. > nested transactions. > > Hopefully this clarifies a bit. > > Niels > > ________________________________________ > From: Clinton Begin [mailto:[EMAIL PROTECTED] > Sent: donderdag 2 juni 2005 0:20 > To: ibatis-user-java@incubator.apache.org > Subject: Re: Calling DAO within TypeHandlerCallback > > > No, but now that you've explained that, it makes sense. With autocommit, > you'll get a separate transaction for each call (which makes sense for that > semantic). > > This might make a great FAQ entry. > > Clinton > > On 5/31/05, Niels Beekman <[EMAIL PROTECTED]> wrote: > Update: > > Strange, when I do not use autocommit-semantics and explicitly demarcate my > transactions, everything goes fine. Well, at least I have a workaround. > > Until now, I used autocommit-semantics for most of my reads, and only > explicitly demarcated when updating/inserting/deleting, should I always use > the latter, even for reads? > > Niels > ________________________________________ > From: Clinton Begin [mailto:[EMAIL PROTECTED] > Sent: dinsdag 31 mei 2005 17:46 > To: ibatis-user-java@incubator.apache.org > Subject: Re: Calling DAO within TypeHandlerCallback > > > DAOs never touch result sets. So I wonder what you mean by that? Similarly, > iBATIS only closes result sets once all columns have been iterated through > (and hence all TypeHandlers have been executed). Unfortunately some drivers > (like IBM's DB2 driver) like to close resultsets automatically when the last > row is read....you're using JTDS, which we've also had a lot of troubling > reports about. Just for giggles, can you try either the Microsoft driver or > the Sybase driver, depending on which database you're using? > > Cheers, > Clinton > > On 5/31/05, Niels Beekman <[EMAIL PROTECTED]> wrote: > Hi, me again :) > > When using a TypeHandlerCallback-implementation that calls the DAO, any > subsequent property that iBATIS tries to fetch results in the following > error (this dump occurred with a Date-property): > > java.sql.SQLException: Invalid state, the ResultSet object is closed. > at > net.sourceforge.jtds.jdbc.JtdsResultSet.checkOpen (JtdsResultSet.java:284 > ) > at > net.sourceforge.jtds.jdbc.JtdsResultSet.findColumn (JtdsResultSet.java:86 > 4) > at > net.sourceforge.jtds.jdbc.JtdsResultSet.getTimestamp(JtdsResultSet.java: > 1225) > at > org.apache.commons.dbcp.DelegatingResultSet.getTimestamp (DelegatingResul > tSet.java:261) > at > com.ibatis.sqlmap.engine.type.DateTypeHandler.getResult(DateTypeHandler. > java:44) > at > com.ibatis.sqlmap.engine.mapping.result.BasicResultMap.getPrimitiveResul > tMappingValue( BasicResultMap.java:544) > at > com.ibatis.sqlmap.engine.mapping.result.BasicResultMap.getResults(BasicR > esultMap.java:303) > at > com.ibatis.sqlmap.engine.execution.SqlExecutor.handleResults(SqlExecutor > .java:363) > at > com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQuery(SqlExecutor. > java:184) > at > com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.sqlExecuteQu > ery(GeneralStatement.java :205) > at > com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQuery > WithCallback(GeneralStatement.java:173) > at > com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQuery > ForObject(GeneralStatement.java :104) > at > com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlM > apExecutorDelegate.java:561) > at > com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject (SqlM > apExecutorDelegate.java :536) > at > com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForObject(SqlMapSes > sionImpl.java:97) > at > com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryForObject (SqlMapClie > ntImpl.java:70) > at > com.ibatis.dao.client.template.SqlMapDaoTemplate.queryForObject (SqlMapDa > oTemplate.java:162) > at > nl.wis.services.dao.impl.sqlmap.SqlMapBaseDaoTemplate.queryForObject (Sql > MapBaseDaoTemplate.java:120) > at <snip> > > When just constructing objects within the handler (as stated in FAQ), > all goes well. I tried to do some debugging and it seems that the inner > DAO-call disposes the resultset, which would obviously result in the > stated error, but I'm not sure this is the case. > > I really like the typehandlers, so hopefully this can be resolved... > > Thanks again, > > Niels > > >
