I´m working on a JMeter testplan which is meant to preformance-test a webservice. The main part of the whole testplan consists of two steps.

1. Retrieve a list of IDs from the server (via Get-request)
2. Take one of these IDs and do something with it (via Post-request)

If I use a singlethreaded plan, everything works out as expected, but as soon as I use more than one thread, I get into a race condition. The problem is, that the 2nd step changes the list of avaiable IDs, thus: if thread B retrieves the ID-list before thread A finished step 2, thread B might get the same ID as thread A which leads to an error when thread B tries to fulfill step 2. Somehow a classical example of race conditions in a multithreaded environment. 
As JMeter doesn´t provide the possibility for defining critical code blocks, I decided to write my own custom Java sampler extending the JMeter-AbstractJavaSamplerClient, overriding runTest() a.s.o. Within the runTest()-implementation I acquire a ReentrantLock and use it to lock the critical code block. The point is, that JMeter doesn´t seem to care about that lock and I simply don´t get why...if I debug my code via remote debugging using Eclipse I see that several threads step into the locked code at the same time, which shouldn´t be the case. I also tried the old fashioned way using synchronize for the complete runTest()-implementation, but that doesn´t work either.

Does anyone have a suggestion what needs to be changed? Or at least an explanation why this doesn´t work?

Thanks in advance!