jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Arnold <>
Subject Re: JDBC sampler - connection pool
Date Sun, 07 Sep 2003 19:06:26 GMT
Ryszard Lach wrote:

>On Sat, Sep 06, 2003 at 02:51:02PM +0200, Jeremy Arnold wrote:
>>With the current code, I think it will just use one of the two pools for 
>>both connections...probably the pool that is accessed first, although 
>>I'm not sure about that.  That's obviously not the correct 
>>behavior...the JDBC Sampler has a few bugs.
>If connection numbers would be equal, then there would be created one or
>two pools? If two, then I don't understand what would be the pools
In the current code, only one pool will be created per JDBC URL, 
regardless of whether or not the other settings match.

>Is the pool active during the whole test, or is reactivated by each
>loop start?
The pool is active for the whole test.  Actually, it might even stay 
active across multiple tests (if you run the test, and then run the test 
again).  Not sure about that.

>Do all the threads use the same pool?
Yes, all threads use the same pool.

>Someone on this list suggested to create a pool as container, which
>would have jdbc samplers as children, but I think it would be better,
>when sampler would automatically use a pool configured in connection
>defaults, eventualy with possibility to uncheck using the pool at all by
>a checkbox in sampler config. I don't think, that one could need more
>that one pool in one fragment of configuration tree.
I'll keep thinking about this...I'll post a proposal for comments before 
I do anything.  My thoughts at the moment are that very few "real" 
applications would have more than one pool for a single database URL, so 
the current behavior really isn't too far off.  The biggest problem with 
the current behavior is that the GUI lets you set the pool parameters on 
each JDBC sampler even though it doesn't actually behave that way.  And 
if there are multiple samplers which use different users then only one 
of the users actually gets used.

So I'm thinking that the solution is probably to always define the 
connection pooling parameters along with the database connection.  These 
could be defined as the connection defaults, which would behave as you 
suggested (I think).  But these could be overridden for particular 
queries if you really wanted to do something differently.

I'll have somewhat limited access to email for the rest of this month.  
I'll still keep up with reading the list, but won't have much 
opportunity to make replies.


View raw message