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 <fschietteca...@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-unsubscr...@ibatis.apache.org > For additional commands, e-mail: user-java-h...@ibatis.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org For additional commands, e-mail: user-java-h...@ibatis.apache.org
