poner - Error de tiempo de espera al intentar bloquear la tabla en h2
subtitulo h2 (7)
Conseguí este problema con el PlayFramework
Se produjo la excepción JPAQueryException: error al ejecutar la consulta desde los modelos. Página donde name =?: Timeout tratando de bloquear la tabla "PAGE"
Terminó siendo un bucle infinito de clases porque tenía un
@Antes de
sin un a menos que causó que la función se llame repetidamente
@Antes (a menos que = "getUser")
Me sale el siguiente error en un determinado escenario
Cuando un subproceso diferente está poblando una gran cantidad de usuarios a través de la operación de carga masiva y estaba tratando de ver la lista de todos los usuarios en una página web diferente. La consulta de lista, arroja el siguiente error de timeout. ¿Hay una manera de establecer este tiempo de espera para que pueda evitar este error de tiempo de espera.
Env: h2 (más reciente), Hibernate 3.3.x
Caused by: org.h2.jdbc.JdbcSQLException: Timeout trying to lock table "USER"; SQL statement:
[50200-144]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:327)
at org.h2.message.DbException.get(DbException.java:167)
at org.h2.message.DbException.get(DbException.java:144)
at org.h2.table.RegularTable.doLock(RegularTable.java:482)
at org.h2.table.RegularTable.lock(RegularTable.java:416)
at org.h2.table.TableFilter.lock(TableFilter.java:139)
at org.h2.command.dml.Select.queryWithoutCache(Select.java:571)
at org.h2.command.dml.Query.query(Query.java:257)
at org.h2.command.dml.Query.query(Query.java:227)
at org.h2.command.CommandContainer.query(CommandContainer.java:78)
at org.h2.command.Command.executeQuery(Command.java:132)
at org.h2.server.TcpServerThread.process(TcpServerThread.java:278)
at org.h2.server.TcpServerThread.run(TcpServerThread.java:137)
at java.lang.Thread.run(Thread.java:619)
at org.h2.engine.SessionRemote.done(SessionRemote.java:543)
at org.h2.command.CommandRemote.executeQuery(CommandRemote.java:152)
at org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:96)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:342)
at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208)
at org.hibernate.loader.Loader.getResultSet(Loader.java:1808)
at org.hibernate.loader.Loader.doQuery(Loader.java:697)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
at org.hibernate.loader.Loader.doList(Loader.java:2228)
... 125 more
Me encontré con el mismo problema y al usar el parámetro "MVCC = true", lo resolví. Puede encontrar más explicaciones sobre este parámetro en la documentación de H2 aquí: http://www.h2database.com/html/advanced.html#mvcc
Me gustaría sugerir que si está recibiendo este error, entonces quizás no debería usar una transacción en su operación de base de datos masiva . Considere, en cambio, realizar una transacción en cada actualización individual: ¿tiene sentido pensar en una importación masiva completa como una transacción? Probablemente no. Si lo hace, entonces sí, MVCC = verdadero o un tiempo de espera de bloqueo mayor es una solución razonable.
Sin embargo, creo que en la mayoría de los casos, está viendo este error porque está intentando realizar una transacción muy larga; en otras palabras, no es consciente de que está realizando una transacción realmente larga. Este fue ciertamente el caso para mí y simplemente me preocupé por cómo escribía los registros (ya sea sin utilizar transacciones o con transacciones más pequeñas) y se resolvió el problema del tiempo de espera de bloqueo.
Para aquellos que tienen este problema con las pruebas de integración (es decir, el servidor está accediendo a la base de datos h2 y una prueba de integración está accediendo a la base de datos antes de llamar al servidor, para preparar la prueba), agregar un ''commit'' al script ejecutado antes de la prueba se asegura de que los datos están en la base de datos antes de llamar al servidor (sin MVCC = true, lo que encuentro es un poco "extraño" si no está habilitado de forma predeterminada).
Sí, puedes cambiar el tiempo de espera de bloqueo . El valor predeterminado es relativamente bajo: 1 segundo (1000 ms).
En muchos casos, el problema es que otra conexión ha bloqueado la tabla, y el uso de la concurrencia de varias versiones también resuelve el problema (adjunto ;MVCC=true
a la URL de la base de datos).
Trabajando con DBUnit, H2 e Hibernate: el mismo error, MVCC = true ayudó, pero todavía obtendría el error para cualquier prueba luego de la eliminación de datos. Lo que solucionó estos casos fue envolver el código de eliminación real dentro de una transacción:
Transaction tx = session.beginTransaction();
...delete stuff
tx.commit();
Tuve MVCC = true en mi cadena de conexión pero aún obtenía el error anterior. ;DEFAULT_LOCK_TIMEOUT=10000;LOCK_MODE=0
y el problema se resolvió