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
> Clinton
>
> Thanks for all the information, I reworked my code and am now keeping
> SqlSessionFactory(ies) around in a hash to create s
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 confi
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
> Clinton
>
> Thanks for the information, a
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 towar
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 diffi
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
