ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From François Schiettecatte <fschietteca...@gmail.com>
Subject Re: iBatis 2.x vs. iBatis 3.x performance
Date Thu, 18 Mar 2010 12:37:08 GMT

Thanks for the information, and indeed my code creating the SqlSessionFactoryBuilder() and
the SqlSessionFactory() is wrong, which I will fix.

However there is an interesting issue around SqlSessionFactory() though, when you take into
account page 5, SqlSessionFactory() is geared toward setting up a factory around a single
host name/database name/user name so does not work so well if you have multiple databases
on multiple hosts. Unless there is a way to set configuration XML file property values when
I create a new session, you have to use SqlSessionFactory().build(reader, properties) for
each host name/database name/user name you access. Or did I miss something here ?



On Mar 17, 2010, at 11:21 PM, Clinton Begin wrote:

> I'm not sure what to say... this is not really an iBATIS issue.  
>   * First, you're purposefully going directly against a key part of the SqlSession contract.
 There's an entire section in the user guide about SqlSession lifecycle (Page 9) and you're
completely ignoring it.  This makes it very difficult to help you.
>   * Keeping sessions (and therefore connections) open for long durations is a very bad
practice.  iBATIS won't do anything to help you there.  We wrap connections with SqlSessions,
thus to abuse one is to abuse the other.
> So I'm not sure there is any help for your situation.  
> The most curious thing about your claim is that creating an iBATIS 3 SqlSession is more
expensive than creating an iBATIS 2 SqlMapClient.  I find that very hard to believe.   
> The creation of the SqlSession is almost nothing.  It's a few class instantiations (almost
free in modern JVMs), some getter/setter calls, some field assignments.  There is one array
and one hashmap created (maybe a little cost there, but not much).  The most expensive line
in the creation of a SqlSession is this one:
>       Connection connection = dataSource.getConnection();
> This is entirely the cost incurred by your choice of DataSource.  
> Compare that to the iBATIS 2 SqlMapClient, which had to parse XML, instantiate various
maps, parse inline parameter maps and do tons of string manipulation.  I just can't believe
that your claim holds true.  I'd love to see some numbers on  that one, and a testing approach.
 Regardless, both creating multiple SqlMapClients and sharing SqlSessions are bad ideas, so
the exercise would be strictly academic.
> So in a nutshell, I'm really not sure what I can do for you other than say:  Best of
> You're going far beyond the intended use of iBATIS and breaking clearly documented rules.
> Sorry. 
> Clinton
> 2010/3/17 François Schiettecatte <fschiettecatte@gmail.com>
> Hi
> I have not heard back from anyone on this issue (which I am running into), is it a bug
or a non-issue?
> I went back and retested it and I get the "CommunicationsException" with the POOLED data
source as well (so my original testing was not up to par).
> For me this will require some amount of rework if I want to minimize the performance
penalty I wrote about.
> Cheers
> François
> On Mar 12, 2010, at 3:54 PM, François Schiettecatte wrote:
> > I did run into some issues with connection pooling. Creating a SqlSession() checks
out a connection from the pool (I presume) and from what I can tell it does not check it back
in until you close the session, so there is room for connections to timeout if I save them
in a hash. With C3P0 I would get a "CommunicationsException: Communications link failure"
when I used a connection which had timed out. On the other hand the built-in POOLED data source
did not have this issue. I was not able to reliably get around this issue in C3P0 either by
extending the timeout at the server end, or by setting up a ping query. Maybe one way to deal
with this would be to check-out a connection from the pool at the start of a transaction and
check it back in at the end of the transaction.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org

To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org

View raw message