¿Debería haber una transacción para consultas de lectura?

Question

He estado leyendo que algunos desarrolladores / dbas recomiendan usar transacciones en todas las llamadas a la base de datos, incluso las llamadas de solo lectura. Si bien entiendo la inserción / actualización dentro de una transacción, ¿cuál es el beneficio de leer dentro de una transacción?

Answer 1

Entonces obtienes una vista consistente de la base de datos. Imagine que tiene dos tablas que se vinculan entre sí, pero por alguna razón hace 2 selecciones ... en pseuodocode:

myRows = query(SELECT * FROM A)
moreRows = query(SELECT * FROM B WHERE a_id IN myRows[id])

Si entre las dos consultas, alguien cambia B para eliminar algunas filas, tendrá un problema.

Answer 2

Similar a lo que dijo RoBorg, haría SELECCIONES con transacciones para evitar la lectura de datos fantasmas entre declaraciones. PERO es importante tener en cuenta que el nivel de aislamiento de transacción predeterminado en SQL Server es LEÍDO COMPROMETIDO, que solo evitará lecturas sucias; para evitar datos fantasmas, debería usar al menos REPEATABLE READ. " Use esta opción solo cuando sea necesario. "

http://msdn.microsoft.com/en-us/library /ms173763.aspx

Answer 3

He encontrado que las 'transacciones' se comportan de manera muy diferente en diferentes servidores SQL. En algunos casos, iniciar una transacción impide que todas las demás conexiones puedan ejecutar cualquier SQL hasta que la transacción se confirme o se revierta (MS SQLServer 6.5). Otros no tienen ningún problema, y ??solo se bloquean cuando hay una modificación (oráculo). Los bloqueos pueden incluso expandirse para abarcar solo sus cambios: bloqueos de celda / bloqueos de fila / bloqueos de página / bloqueos de tabla.

Normalmente, uso transacciones solo cuando se debe mantener la integridad de los datos entre múltiples declaraciones de inserción / eliminación / actualización. Aún así, prefiero implementar esto usando eliminaciones en cascada definidas por DB para que la base de datos lo haga de forma automática y atómica.

Use una transacción si puede prever una situación en la que desea deshacer múltiples modificaciones, pero de lo contrario, la base de datos realizará sus actualizaciones atómicas sin el código adicional para tratarla.

Answer 4

He estado revisando esto en los últimos minutos, ya que es algo sobre lo que debería saber más. Esto es lo que he encontrado.

Las transacciones serían útiles alrededor de una selección si desea bloquear esa fila mientras una persona está leyendo registros y no quiere que se modifique o lea. Por ejemplo, ejecute estas consultas:

(en la ventana de consulta 1)

COMENZAR TRAN SELECCIONAR * DE MYTABLE CON (ROWLOCK XLOCK) DONDE ID = 1

(en la ventana de consulta 2)

SELECCIONAR * DE MYTABLE DONDE ID = 1

(la ventana de consulta 2 no devolverá resultados hasta que ejecute esto en la ventana 1)

COMPROMISO TRAN

Enlaces útiles:

http://msdn.microsoft.com/en-us/library /aa213039.aspx

http://msdn.microsoft.com/en-us/library /aa213026.aspx

http://msdn.microsoft.com/en-us/library /ms190345.aspx

Mi objetivo era conseguir algo para bloquear, y finalmente funcionó después de agregar el XLOCK allí. Simplemente usar ROWLOCK no estaba funcionando. Supongo que estaba emitiendo un bloqueo compartido (y los datos habían sido leídos) ... pero aún estoy explorando esto.

Agregar - WITH (UPDLOCK ROWLOCK) - le permitirá seleccionar y bloquear las filas para las actualizaciones, lo que ayudaría con la concurrencia.

Tenga cuidado con las sugerencias de tabla. Si comienza a aplicarlas al azar, su sistema se ralentizará si obtiene incluso un pequeño número de usuarios en su aplicación. Eso es lo único que sabía antes de investigar esto;)

Answer 5

Diría que uno de los propósitos principales de una transacción es ofrecer un potencial de reversión si hay algún problema, lo que no funciona cuando simplemente se lee.