Bloqueo de ficha

([N4] Juega) #1

Buenas tardes

Tengo el siguiente problema.

tabla de cabecera con un histórico de líneas

Esta tabla cabecera tiene un id siguiente al último y un campo (no indexado) cuyo valor depende de una tabla contadores
En el triger previo al alta de la tabla cabecera se lanza un proceso que lee la tabla contadores y suma 1 al último y guarda la ficha.
Después se modifica el campo de la tabla cabecera.

Cuando hay varios usuarios haciendo altas en la tabla cabecera se producen bloqueos en la tabla contadores y como resultado se deshace toda la transacción.

He probado de todo pero no consigo evitar el bloqueo.
Alguien ha tenido el mismo problema y lo ha resuelto?

Gracias
Carlos Juega

([N3] pacosatu) #2

Hola Carlos.

  • Revisa la transacción (la que afecta a Contadores) con el vAdmin.
  • Revisa exactamente cuándo se inicia la Transacción y cuándo termina. Pon mensajes en 1P y 3P.
  • Revisa que la transacción que bloquea la tabla de Contadores NO está incluída en otra transacción mayor.
  • Intenta aislar la transacción que graba en la tabla Contadores y que dure lo menos posible.
  • La secuencia Leer el contador -> Incrementar contador -> Grabar contador no debe durar más de unas céntimas de segundo.

Saludos
Paco Satué

([N4] Juega) #3

Buenas tardes Paco

Gracias por la respuesta.
Ya había probado todo lo que indicas.
De hecho, no parece haber solución según soporte.
Lo que me indican es que haga la modificación después de hacer el alta. Algo que me resistía a hacer porque no me parece lógico ni eficiente tener que grabar un registro para luego modificarlo.

Lo que creo es que el triger anterior al alta bloque todo los que usa y no lo suelta hasta que acaba. Aunque la lectura de la tabla de contadores sea muyrrápida (solo lee y graba un registro pequeño) en un entorno multiusuario será inevitable que en algún momento haya colisión.

Espero que cuando haga las pruebas en el evento posterior al alta, la ficha esté liberada porque de lo contrario me temo que estoy jodido.

Saludos
Carlos Juega

([N3] pacosatu) #4

Hola Carlos.

No entiendo el problema y mucho menos la respuesta de Soporte. Velneo es un sistema transaccional, multiusuario y con gestión de bloqueos y este escenario está totalmemte contemplado.

Cuando un usuario consigue bloquear el registro de CONTADORES, los demás usuarios harán intentos de bloqueo una o varias veces y si no lo consiguen se deshace la transacción.

Creo que son 3 intentos cada 4 segundos, en total estaría 12 segundos intentando el bloqueo. Consúltalo a Soporte.

Como la transacción en el registro de CONTADORES dura centésimas de segundo, todos los usuarios tendrán acceso en el primero o segundo intento de bloqueo.
Otra cuestión es que la transacción que bloquea el registro de CONTADORES dure más de la cuenta y se estén produciendo Timeouts en los intentos de bloqueo del resto de Usuarios.
Dices:

Lo que creo es que el triger anterior al alta bloque todo los que usa y no lo suelta hasta que acaba.

Crees bien. El Trigger está metido en una transacción que habrá sido creada por un Modificar ficha y ésta a su vez puede estar metida en otras transacciones. Todo lo que haga el Trigger se engloba en una única transacción, por lo tanto pueden verse implicadas muchas operaciones de bloqueo si no lo controlamos bien.

Si descartamos que se produzcan interbloqueos, la única razón de tu problema es un bloqueo que dura más de lo que permite el timeout de Velneo.

Por esta razón dinos cuánto dura exactamente la transacción que engloba el bloqueo del registro de CONTADORES. Intenta igualmente sacar del trigger la actualización de CONTADORES y lo aislas en una transacción independiente.

Saludos
Paco Satué

([N1] wikan) #5

Me extraña mucho tu problema, he tenido algún tema de bloqueos pero sobre todo era problema mío.

No se si la tabla de contadores tendrá un enlace maestro a la cabecera, que tampoco estaría mal. Podrías hacer lo mismo con una actualización de la cabecera a contadores acumulando 1. No se si te soluciona el problema del bloqueo, pero hablamos de milisegundos en un alta bien realizada y además que varios usuarios lo hagan en el mismo instante.

Por otro lado lo que te comenta Paco, las transacciones deben asegurar que cada usuario accede por separado.

([N2] Esfero) #6

Hola, no se si lo habras probado, o si encajaría en tu solución, pero puesto que si creas una función velneo está siempre transaccina de forma independiente, ¿has probado a obtener el número del contador a través de una función?
Ej: modificar campo (contador, fun:buscoContador())
Obviamente de esta forma aunque la transacción de la cabecera se deshiciera, la del contador se ejecutaría igualmente y avanzaría el contador.

([N4] Infortic) #7

Hombre, por fin una utilidad a que las funciones transaccionen por su cuenta.

Siempre me ha parecido una aberración ese comportamiento, pero aquí serviría.

([N3] pacosatu) #8

Hola.

Siento chafaros la ilusión.

Las funciones solo generan transacción independiente en 1P.
En 3P se integran siempre en la transacción actual.

Por lo tanto, solo desde el primer plano es posible actualizar CONTADORES y hacerlo con transacción independiente.

Saludos
Paco Satué

([N2] Esfero) #9

Vaya, pues no se dice nada al respecto en la documentación, si bien es cierto que en la documentación especifica que solo se pueden ejecutar en primer plano aunque no entiendo bien esta afirmación que ponen, si queda muy claro que siempre transacciona.

“Si la función genera transacción (escribe en la bb.dd.) siempre generará una transacción independiente. Esto quiere decir que, si ejecutamos un proceso que transacciona y desde él llamamos a una función que también transacciona, no quedará todo englobado en una única transacción, sino que se generarán dos transacciones independientes: La del proceso y la de la función.”

([N3] pacosatu) #10

Hola Esfero.

Lo mejor es que lo pruebes. A falta de documentación clara al respecto, como siempre el método de Prueba y Error.

Saludos
Paco Satué

([N4] Infortic) #11

Vaya tela… por si ya me parecía absurdo que la función transaccionara por fuera de la transacción activa ahora resulta que el comportamiento es distinto según el plano.

Bueno es saberlo, no me había dado cuenta.

([N4] Juega) #12

Buenas tardes a todos

Otra vez gracias a todos por el interés.

Pasado el momento de pánico os comento

La alternativa de las funciones no sirve. Lo digo porque ya la desestimamos hace tiempo cuando comprobamos que, como dice Paco, solo transacciona en 1P. En 3P, que es como tratamos de ejecutar siempre los procesos, teníamos el mismo problema. Por esa razón lo sacamos del proceso y lo pusimos en el triger.
En este caso concreto, además no hay opción. Todo se lanza en 3P porque los clientes son PDA que tienen que ir a toda pastilla.

De esto hace más de 2 años, así que nos olvidamos del asunto.

Por eso, el sentido común me decía que esto no podía ser, que ya debería haber saltado antes el problema, y no solo a nosotros.

Así que he montado un test que ejecuto desde 3 equipos distintos simultaneamente grabando registros sin parar.
No hay ningún bloqueo en el triger y el contador funciona perfectamente.

Por lo tanto, el problema es nuestro, de modo que toca revisar el código otra vez.

De nuevo gracias a todos

Saludos
Carlos Juega

([N1] wikan) #13

Estamos hablando de un problema que tuviste hace 2 años y ahora lo retomaste?

Al ser PDA puede ser por temas de conexión.

([N4] Juega) #14

No

Lo que quería decir es que tuve un problema parecido hace dos años.

Ahora es una nueva instalación más grande y en otro cliente.

Carlos Juega