ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven Boden <list...@pandora.be>
Subject Re: Calling DAO within TypeHandlerCallback
Date Thu, 09 Jun 2005 16:55:33 GMT

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 <niels@wis.nl> 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:brandon.goodin@gmail.com]
>> 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 <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