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 22:51:07 GMT
Clinton

Thanks for all the information, I reworked my code and am now keeping SqlSessionFactory(ies)
around in a hash to create sessions from them as I need them. I will check into the named
environments as you suggest. Meanwhile a suggestion would be to have a way to pre-parse the
iBatis configuration and allowing one to apply a set of properties on demand, so splitting
the reader step and properties step in this process:

	sqlSessionFactoryBuilder.build(reader, properties);

make sense? Not sure how feasible or desirable this is given that I can keep SqlSessionFactory(ies)
resident.

Thanks again

François

On Mar 18, 2010, at 6:37 PM, Clinton Begin wrote:

> You can also use named environments to manage different databases.  And yes, you'd need
a single SqlSessionFactory for each -- but I wouldn't create them on demand.  I'd instantiate
them and keep them resident.
> 
> Clinton
> 
> 2010/3/18 François Schiettecatte <fschiettecatte@gmail.com>
> Clinton
> 
> 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 ?
> 
> Cheers
> 
> François
> 
> 
> 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 luck.
> >
> > 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
> 
> 


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


Mime
View raw message