SqlBulkCopy. WriteToServer не надежно повиновение BulkCopyTimeout

Я должен считать последовательные исключения тайм-аута из SqlBulkCopy. Для тестирования этого я использую внешнее приложение, чтобы запустить транзакцию и запереть целевую таблицу.

Только на первом вызове делает SqlBulkCopy, выдают исключение тайм-аута при ожидании. Мы попытались использовать внешнее соединение и транзакцию, а также использовать строку подключения и внутреннюю транзакцию. С внешним соединением и транзакцией, бесконечное ожидание никогда не было в открытии соединения или начало или фиксация транзакции, но всегда в .WriteToServer().

Есть ли некоторый подход к этому посредством чего SqlBulkCopy.WriteToServer() надежно выдаст исключение тайм-аута, когда оно достигнет .BulkCopyTimeout предел?

public void BulkCopy(string connectionString, DataTable table, int bulkTimeout)
{
    using (SqlBulkCopy bulkCopy = new SqlBulkCopy(
        connectionString, 
        SqlBulkCopyOptions.UseInternalTransaction))
    {
    bulkCopy.BulkCopyTimeout = bulkTimeout;//e.g. 120 sec.
    //... fill with data, map columns...
    bulkCopy.WriteToServer(table);
    // ^^^^ waits indefinitely, doesn't throw until *after*
    //      the lock is released.
    }
}

Я предпочитаю позволять пузырю исключений, а не обрабатывать их в пределах using блок, но я могу всегда повторно бросать. Большое спасибо за любое понимание.

Обновление 1:

Все еще никакое разрешение. Интересное поведение обнаружило, хотя - нормальный SqlCommand бросит TimeoutException как ожидалось во время той же блокировки, которая делает SqlBulkCopy. Метод WriteToServer зависает неограниченно долго.

Вот подходы, которые мы попробовали - и которым не удалось - получить SqlBulkCopy. WriteToServer для последовательного броска тайм-аутов при ожидании:

• МАРС (несколько активных наборов результатов) вкл\выкл
• TableLock на по сравнению с прочь
• Место назначения как таблица "кучи" по сравнению с индексированной таблицей
• Более длинные/короче значения BulkTimeout (10 секунд к 5 минутам)
• Внутренний по сравнению с внешней транзакцией

На данный момент, как обходное решение, я чередуюсь между a) помещением WriteToServer звонят в асинхронную обертку, таким образом, я могу время это сам и b) только вызовом WriteToServer однажды; после тайм-аутов ожидайте, пока обычный SqlCommand не успешно выполняется прежде, чем попробовать WriteToServer снова. Используя эти подходы, я, по крайней мере, могу остаться в управлении потока выполнения.