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
>
>
