¿Por qué configurar Autocommit en true?

Question

Me he preguntado durante mucho tiempo por qué la API de JDBC proporciona un modo de confirmación automática (java.sql.Connection.setAutocommit()). Parece una molestia atractiva que solo atrae a la gente a problemas. Mi teoría es que solo se agregó a JDBC para simplificar la vida de los proveedores que querían crear herramientas para editar y ejecutar SQL utilizando JDBC. ¿Hay alguna otra razón para activar el compromiso automático o siempre es un error?

Answer 1

Desafortunadamente, el uso de autocommit es específico de la base de datos (como es el comportamiento de la transacción). Creo que si no tienes una estrategia global de transacciones programáticas, la confirmación automática es probablemente mejor que simplemente esperar que todos cierren/cancelen las transacciones correctamente.

Hablando en MySQL, puede dejar autocommit = true activado de forma predeterminada, y se apagará automáticamente cuando COMIENCE una transacción. La única razón para establecer autocommit = false es si desea forzar un error si alguien intenta iniciar una transacción sin un BEGIN.

Para simplificar en una aplicación Java + MySQL típica de hoy, me gustaría más o menos ignorar la configuración de confirmación automática, utilizar un patrón de sesión abierta en vista y llamarlo bueno.

Desaconsejaré explícitamente los bloqueos de fila de RDBMS explícitos y utilizaré en su lugar cerraduras optimistas. Hibernate ofrece soporte integrado para bloqueos optimistas, pero es un patrón fácil de adoptar incluso para código enrollado a mano y ofrece un mejor rendimiento.

Answer 2

El modo de compromiso cambia la forma en que el db mantiene bloqueos.

Se recomienda desactivar el modo de confirmación automática solo durante el modo de transacción. De esta forma, evitará mantener bloqueos de base de datos para varias sentencias, lo que aumenta la probabilidad de conflictos con otros usuarios.

...

Para evitar conflictos durante una transacción, un DBMS utiliza cerraduras, mecanismos para bloquear el acceso de otros a los datos que se esté accediendo a la transacción. (Tenga en cuenta que en el modo auto-commit, donde cada declaración es una transacción, bloqueos se mantienen durante una sola declaración.)

http://download.oracle.com/javase/tutorial/jdbc/basics/transactions.html

Answer 3

única razón razonable que puedo ver es la de deshacerse de la connection.commit() y connection.rollback() repetitivo en transacciones sencillas de consulta simple en aplicaciones pequeñas. JDBC en forma cruda requiere por sí solo una gran repetición. Cada línea menos hace que JDBC sea menos aterrador para los principiantes.

Answer 4

El 95% de la base de código con la que estoy trabajando ahora implica actualizaciones únicas donde la confirmación automática es perfectamente razonable. Por lo tanto, estamos predeterminados para eso. Solo lo apaga el tiempo suficiente para hacer las secciones de código que deben ser una transacción, ¡y luego vuelve a activarse automáticamente!

Answer 5

Casi siempre funciono con autocommit = true. 99% del tiempo, mis actualizaciones son atómicas. Claro, hay casos en los que escribe el débito y luego falla al intentar escribir el crédito que desea revertir. Pero en mi experiencia, estos son relativamente raros. Por lo general, cada registro que escribo se sostiene por sí mismo. En ese caso, no es necesario preocuparse por hacer una confirmación después de cada escritura es conveniente. Guarda una línea de código aquí y allá. Puede ahorrar más que eso si, dada la estructura del programa, significa que no necesito un bloque try/catch adicional o que no necesito pasar un objeto de conexión entre funciones. Ahorra en molestos errores donde alguien olvidó hacer un commit.

La única forma en que veo que podría "atraer a alguien a problemas" es que decide desactivar Autocommit y realizar la confirmación o reversión es demasiado problema, por lo que realiza actualizaciones que deben realizarse en una transacción individualmente. Entonces todo parece funcionar bien siempre y cuando no pase nada que deba abortar la transacción. Si los escenarios de prueba son inadecuados, podría imaginarse que esto se deslice hacia la producción.

Pero podría decir lo mismo sobre casi cualquier característica de un idioma. Como, supongamos que escribes un programa que procesa números que el 90% del tiempo cabrán en un largo, pero de vez en cuando puede ser más grande. Frente a esta situación, lo correcto es usar BigInteger o crear una nueva clase para manejar los números más grandes. Un programador perezoso puede ser atraído a usar mucho porque normalmente funcionará y otras alternativas son demasiados problemas. ¿Concluiría por lo tanto que Java no debería incluir long (o int) porque alguien podría ser atraído a usarlos cuando no son apropiados?

Si en sus programas la mayoría de las actualizaciones deben realizarse dentro del contexto de una transacción, desactive la confirmación automática. Su presencia no te hace daño. Está ahí para cuando sea conveniente, pero cuando no lo esté, puede apagarlo.

Answer 6

La confirmación automática es conveniente; pero con los cambios a la especificación JDBC 3, se ha vuelto mucho menos útil.

Dado que las 3 conexiones JDBC en modo "confirmación automática" no pueden tener más de una instrucción abierta. Al ejecutar otra instrucción, se cerrará la primera, incluido cualquier ResultSet.

Por lo tanto, el bucle dentro de un SELECCIONAR y emitir ACTUALIZACIONES (o incluso SELECT anidados) tenderá a fallar. Al parecer, es un crimen, para realmente querer hacer algo con los resultados de su SELECCIÓN externa!

---

De todos modos, depende de la versión específica del conductor & .. pero en general la especificación JDBC 3 aparece con el mandato de este comportamiento poco útil. La actualización de los controladores también puede "descubrir" inútilmente este comportamiento.

¿Por qué utilizar el autocompromiso? Originalmente, fue útil & conveniente. Como dicen otras respuestas, JDBC requiere grandes cantidades de GUFF y gastos de envío para llamar correctamente .. JDBC no es realmente una API bien diseñado :(

---

En estos días, que sería mejor usar Hibernate o JdbcTemplate de primavera. . Y si está haciendo servlets/aplicaciones web, coloque su gestión de transacciones (inicio/fin) o hibernación de sesión (vincúlelo a un hilo local) en los límites de la "Solicitud de usuario"

por ejemplo, obtener enlazar su conexión/transacción al inicio de ServletRequest y devolverlo al final.

Puede usar un javax.servlet.Filter o similar y vincularlo a un local de subprocesos, hacer un ayudante estática para conseguirlo o requiere que, etc.

Answer 7

Bueno, hay ciertas condiciones que necesita una cuidadosa mirada al tiempo que permite la “auto-entrega” a nivel mundial:

a.) La gestión de transacciones en el nivel de consulta quedará a criterio del usuario; para una instancia, si se necesita una gran cantidad de consultas para tener éxito o fallar juntas, entonces se debe ajustar en BEGIN y confirmar Transacción.

b.) Recuerde, no hay retroceso cuando se activa la "confirmación automática".

c.) También hay una sobrecarga de escribir (cometer) todas y cada una de las transacciones.

d.) Para las consultas de solo lectura no existe una necesidad explícita de "autocompromiso", pero habilitando "autocompromiso" se aplica automáticamente para todas las consultas.

Si el bloqueo de tablas es la única preocupación para habilitar el autocompromiso, entonces puede que no sea una buena idea, más bien se puede recurrir a tiempos de espera de bloqueo más bajos.