How big is the 'window of opportunity' for the race condition? Ie. What are the approximate minimum and maximum times between the start transaction/end transaction brackets? Your server logs should be able to supply that information.

If the minimum time between start and end of transaction is (say) more than 1 second ...

When you do your testing, is the server?

• In the same box.
• On the same subnet.
• The otherside of the world connected via 2 cups and a bit of string. :)

... and you run your tests against a server in the same box or even on the same subnet ...

Then arranging for two requests to arrive within that 1 second window using system, fork or threads shouldn't be hugely difficult. Other implications about thread/fork safety of your test tools is an open question. I've seen several reports here of forking test suites failing under Win32 fork emulation for example.

Using threads it might look something like:

use threads;
use Time::HiRes qw[ time ];
use Test::Whatever;

...

## Pick a time in the future
my $go = time() + 0.1;
async {
    ## Make sure client 2 goes off last (and so should fail)
    $go += 0.005;
    sleep 0 while  time() < $go;
    nok( doXML_RPCrequest( 'some request' ) == SUCCESS );
    sleep 0;
}->detach;

sleep 0 while  time() < $go;
ok( doXML_RPCrequest( 'some request' ) == SUCCESS );

... rest of tests.
[download]

On my single processor system using threads, I can arrange for two tcp requests to arrive at the server in the desired order (success before failure), within ~10 milliseconds of each other, ~997 times out of 1000. And 100% reliability (several runs of 1000 tests), if I widen the acceptable window to 20 milliseconds.

So, reliably hitting a window of (say) > 1/10th of a second wouldn't be too difficult if your tests and server run within the same box. If your test box has multiple cpus, arranging finer timing may be possible. Obviously, the bigger the window the easier the task.

An additional possibility is to go the white box route and and artificially widen the window of opportunity by building a test mode into your server. If a particular form of request is received, arrange to have a short sleep (1 or 2 seconds should be ample), to occur within the transaction brackets. That would make arranging to hit the window much easier, at the cost of modifying the code under test in a subtle way. Using this method you could even test the two cups and a bit of string scenario from above by just widening the window to some ludicrous amount.

Whether the risk that someone might accidentally 'remove' or otherwise bypass the enablement of DB transactions at some future point, is worth the extra complexity to bother testing for it, only your judgement can decide.