ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niels Beekman" <ni...@wis.nl>
Subject RE: Calling DAO within TypeHandlerCallback
Date Tue, 14 Jun 2005 09:02:51 GMT
Hi,

I do have an acceptable workaround now by setting SQLMaps to use
EXTERNAL-transactionmanager. I use JTA now, which I wanted to
investigate anyway. Leaves me with the problem of autocommit-semantics,
i.e. an exception still occurs when no transaction is started
externally.

The "only" thing iBATIS should do for me is remember whether the
resources openened are still used inside the DAO-call as described in
earlier mails; so instead of immediately closing SqlExecutor(?) at the
end of a DAO-call, first perform a check if there are DAO-calls active.
Savepoints sounds like a lot of work to me, I do not think you should
spend to much precious time on that, at least, as far as I'm concerned
:)

Any new thoughts on this?

Thanks,

Niels

-----Original Message-----
From: Brandon Goodin [mailto:brandon.goodin@gmail.com] 
Sent: donderdag 9 juni 2005 14:20
To: ibatis-user-java@incubator.apache.org
Subject: Re: Calling DAO within TypeHandlerCallback

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