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 <[email protected]>
> 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 <[email protected]>
> > 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: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
