El código de razón 68 ya indica que esto se debe a un tiempo de espera de bloqueo (interbloqueo es el código de razón 2) Puede deberse a que otros usuarios ejecuten consultas al mismo tiempo que utilizan los mismos datos a los que está accediendo o tus propias actualizaciones múltiples.
Comience por ejecutar db2pd -db locktest -locks show detail desde una línea de comando db2 para ver dónde están los bloqueos. A continuación, necesita ejecutar algo como:
select tabschema, tabname, tableid, tbspaceid
from syscat.tables where tbspaceid = # and tableid = #
llenado de los símbolos # con el número de identificación que se obtiene de la salida db2pd comando.
Una vez que vea donde los bloqueos son, aquí están algunos consejos:
frecuencia ◦Deadlock veces puede reducirse al asegurar que todas las solicitudes de acceso a sus datos comunes en el mismo orden - es decir, por ejemplo, que acceden (y, por lo tanto, bloquear) filas en la Tabla A, seguida de la Tabla B, seguida de la Tabla C, y así sucesivamente.
tomado de: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.trb.doc/doc/t0055074.html
lectura recomendada: http://www.ibm.com/developerworks/data/library/techarticle/dm-0511bond/index.html
Adición: si su servlet o de otra aplicación culpable es el uso de select declaraciones encontrado a participar en el callejón sin salida, puede intentar anexar with ur a las sentencias de selección si la precisión de los datos recién actualizados (o insertados) no es importante.
Es importante tener en cuenta que el artículo habla de ** reducir ** la frecuencia de interbloqueos, no ** impidiendo ** por completo. De acuerdo con http://stackoverflow.com/a/112256/14731, el orden de bloqueo constante no evita los bloqueos. Lo máximo que podemos hacer es intentar reducir su frecuencia. – Gili