ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: Calling DAO within TypeHandlerCallback
Date Wed, 01 Jun 2005 22:19:38 GMT
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 <niels@wis.nl> 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:clinton.begin@gmail.com]
> 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 <niels@wis.nl> 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
> 
>

Mime
View raw message