ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brandon Goodin <brandon.goo...@gmail.com>
Subject Re: Calling DAO within TypeHandlerCallback
Date Fri, 03 Jun 2005 11:53:51 GMT
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 <niels@wis.nl> 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:clinton.begin@gmail.com]
> 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 <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