Additionally, at least for Oracle I'm at least aware of some "issues" with savepoints/rollbacks as described in http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:18202801725435
Regards, Sven Boden On Thu, 9 Jun 2005 06:20:28 -0600, you wrote: >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 >> > >> > >> > >>
