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
