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: [email protected] 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
