ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: iBatis 2.x vs. iBatis 3.x performance
Date Thu, 18 Mar 2010 22:59:33 GMT
It's already separate.  If you look at the code, you can create a
Configuration and pass it directly to the builder.

Clinton

2010/3/18 François Schiettecatte <fschiettecatte@gmail.com>

> 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