2
votes

In JMeter (v2.13 r1665067), I'm using the tearDown Thread Group to delete all of the left-over records that remain after a test run.

The odd thing I can't quite figure out:

  • When the Thread Group is executed in isolation (i.e., by itself), I am able to see the left-over records are deleted from within the database.

  • When the Thread Group is run as part of the full run (i.e., the full end-to-end test plan), the left-over records are not deleted from within the database.

Looking in SQL Profiler, it "appears" the DELETE is sent, yet the records remain in the db. Could it be my Constant Throughput settings or some other timing? Can anyone shed any light on why this happens only during a full run?

In the Test Plan, the Run tearDown Thread Groups after shutdown of main threads is enabled.

Here's what is in my tearDown Thread Group:

JDBC Connection Configuration

Variable Name = myPool
Connection Pool Config
    Max # of Connections = 10
    Pool Timeout = 5000
    Idle Cleanup Interval (ms) = 60000
    Auto Commit = True
    Transaction Isolation = TRANSACTION_SERIALIZEABLE
Connection Validation by Pool
    Keep-Alive = True
    Max Connections Age = 5000
    Validation Query = null

JDBC Request 1

Variable Name = myPool
Query Type = Prepared Update Statement
    DELETE FROM Foo 
    WHERE Foo.QualifierObjId IN 
    (SELECT Bar.ObjId FROM Bar WHERE Bar.DsplyName like '%myTest%');

JDBC Request 2

Variable Name = myPool
Query Type = Prepared Update Statement
    DELETE FROM Bar WHERE Bar.DsplyName like '%myTest%';

JDBC Request 3

Variable Name = myPool
Query Type = Prepared Update Statement
    DELETE FROM Master WHERE Master.DsplyName like '%myTest%';
1
Please indicate what version of JMeter you are using. Is it the latest?user1697575
JMeter Version 2.13 r1665067.David
Perhaps something to do with "Variable Name = myPool"...not sure where do u use var name? May be in a full run its gets synchronisation issues as a result suppressing some of the delete calls?user1697575
Yep! That was it.... It was getting confused between this thread group's myPool and previous thread group's myPool.David
@user1697575 You rock!David

1 Answers

1
votes

Solution

If you are using multiple JDBC Connections spread across multiple Thread Groups, be sure to have unique Variable Names bound to each Pool. I was using "myPool" for each JDBC Connection (basically due to copy/paste) and it was causing the issue. (my bad!)

The solution is:

  • Thread Group 1, JDBC Connection Configuration, Variable Name = myFooPool
  • Thread Group 2, JDBC Connection Configuration, Variable Name = myBarPool
  • tearDown Thread Group, JDBC Connection Configuration, Variable Name = myTearDownPool

Creating unique variable names for each Pool provides clarity between each JDBC configuration and avoids issues such as mine. Hope this helps someone else.