I put it in JIRA just the other day. :) I'll look at it this weekend. The real thing we need to discuss is how to provide an intuitive means for people to configure the jdbc version they are using. We want to be able to provide clear exceptions when someone who is not using jdbc3 trys to use one of it's features. That is the only i am waiting to discuss with larry and clinton.
Brandon On 6/9/05, Niels Beekman <[EMAIL PROTECTED]> wrote: > Hi, > > I there any chance a solution like savepoint-support gets implemented > soon? And are savepoints not too heavy for some simple reads? From the > spec: > > "The representation of a savepoint, which is a point within the current > transaction that can be referenced from the Connection.rollback method. > When a transaction is rolled back to a savepoint all changes made after > that savepoint are undone." > > Since there are no changes when just reading, this sounds as a complex > solution. Any thoughts on all these questions? > > Thanks, > > Niels > > -----Original Message----- > From: Brandon Goodin [mailto:[EMAIL PROTECTED] > Sent: vrijdag 3 juni 2005 13:54 > To: ibatis-user-java@incubator.apache.org > Subject: Re: Calling DAO within TypeHandlerCallback > > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > 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 <[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: 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 > > > > > > >
