SqlBulkCopy.WriteToServer no obedece confiablemente a BulkCopyTimeout

Question

Necesito contar las excepciones de tiempo de espera secuencial desde SqlBulkCopy. Para probar esto, utilizo una aplicación externa para iniciar una transacción & para bloquear la tabla de destino.

Solo en la primera llamada SqlBulkCopy lanza una excepción de tiempo de espera cuando se espera. Intentamos usar una transacción de conexión externa &, así como también usar una cadena de conexión y una transacción interna. Con la transacción de conexión externa &, la espera infinita nunca fue abrir la conexión o comenzar o comprometer la transacción, sino siempre al .WriteToServer().

¿Hay alguna forma de abordar esto mediante el cual SqlBulkCopy.WriteToServer() arrojará de manera confiable una excepción de tiempo de espera cuando haya alcanzado su límite .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. 
    } 
} 

Prefiero dejar excepciones brotan en lugar de manejarlos en el ámbito del bloque using, pero siempre se puede volver a lanzar. Muchas gracias por cualquier idea.

Actualización 1:

Todavía no hay resolución. Sin embargo, se descubrió un comportamiento interesante: un SqlCommand normal lanzará una TimeoutException como se esperaba durante el mismo bloqueo que hace que el método SqlBulkCopy.WriteToServer se cuelgue indefinidamente.

Éstos son los enfoques que hemos probado - y que han fracasado - para obtener SqlBulkCopy.WriteToServer para lanzar consistentemente los tiempos de espera cuando se espera:

• MARS (múltiples conjuntos de resultados activos) ON/OFF
• TableLock en vs. off
• Destino como tabla de montón vs. tabla indexada
• valores BulkTimeout más cortos más largos/(10 segundos a 5 minutos)
• interna vs transacción externa

Por el momento, como alternativa, estoy alternando entre a) poner la llamada WriteToServer en un contenedor asíncrono para que yo pueda temporizarlo, yb) llamar solo a WriteToServer una vez; después de los tiempos de espera, espere hasta que un SqlCommand regular tenga éxito antes de intentar WriteToServer nuevamente. Usando estos enfoques, al menos puedo mantener el control del flujo de ejecución.

Answer 1

¿Ha intentado pasar la opción SqlBulkOptions.TableLock a SqlBulkCopy? Esa opción (presupuesto) significa que lo hará:

Obtenga un bloqueo de actualización masiva para la duración de la operación de copia masiva .

Por lo tanto, si hay otro procesamiento que bloquea la mesa, evitaría que se ganara el bloqueo y, en teoría, se agotaría el tiempo de espera.

Actualización:
creé mi propio instrumento de prueba y no pueden reproducirse. Para bloquear la mesa, comencé una transacción en SSMS haciendo un SELECT * FROM TargetTable WITH (HOLDLOCK).Usé el mismo método BulkCopy que incluyó en la pregunta, usando transacciones internas, con un tiempo de espera de carga masiva de 30 segundos. Cada intento de hacer la copia masiva agota el tiempo esperado después de 30 segundos. Luego tiene éxito cuando deshago la transacción SSMS.

Estaba usando SQL Server 2008 Express, .NET 3.5.

¿No es algo así como después del primer intento, el tiempo de espera de carga masiva no se está pasando correctamente? es decir, de alguna manera no se establece en "indefinido".

Actualización 2:
también cambió en múltiples conjuntos de resultados activos apoyo en la cadena de conexión, siendo constantemente el tiempo de espera para mí cada vez.

Answer 2

Tuve este problema más tarde y para resolver este problema establecí BulkCopyTimeout en cero.

bulkCopy.BulkCopyTimeout = 0;