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