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