This may be related to MCOL-66 being worked upon right now by David.Hall

This is caused by a combination of two things. First, the VSS can't handle transactions arriving out of order if they are acting on the same block. Second, since VSS access is down the execution path, simultaneous threaded transactions arrive in unpredictable order based on cpu cycles given to each thread by the scheduler. Sometimes these two properties clash and result in a transaction being rejected.

I've created a mechanism to serialize transactions only within each table. Transactions on different tables continue concurrently. The mechanism is surrounded by an ifdef, so it will be easy to turn off when we start testing a new VSS.

The mechanism is thus (as documented in the code):
// Blocks a thread if there is another trx working on the same fTableOid
// return 1 when thread should continue.
// return 0 if error. Right now, no error detection is implemented.
//
// txnid was being created before the call to this function. This caused race conditions
// so creation is delayed until we're inside the lock here. Nothing needs it before
// this point in the execution.
//
// The algorithm is this. When the first txn for a given fTableOid arrives, start a queue
// containing a list of waiting or working txnId. Put this txnId into the queue (working)
// Put the queue into a map keyed on fTableOid.
//
// When the next txn for this fTableOid arrives, it finds the queue in the map and adds itself,
// then waits for condition.
// When a thread finishes, it removes its txnId from the queue and notifies all. If the queue is
// empty, it removes the entry from the map.
// Upon wakeup from wait(), a thread checks to see if it's next in the queue. If so, it is released
// to do work. Otherwise it goes back to wait.
//
// There's a chance (CTRL+C) for instance, that the txn is no longer in the queue. Release it to work.
// Rollback will most likely be next.
//
// A tranasaction for one fTableOid is not blocked by a txn for a different fTableOid.

A new test212 has been added to the regression suite to test multiple threads doing DML on single tables. The test runs up multiple tables and multiple threads for each table and then slams DML at them.

This is really a Kludge. Eventually we need to re-engineer the VSS to not need things arriving in order. However, that is an expensive and risky operation, so we have this kludge. Have fun following the flow!

Review Completed

David.Hall Has this been run through regression ? If so please assign to dleeyh for auto pilot testing

Have been testing in Autopilot's concurrent DDL and DML tests. All good.