¿Bloqueo de registro?

[BECERRA]

Hola compañeros:

He realizado una aplicación en interbase, y en ocasiones, cuando dos o mas usuarios introducen registros en la misma tabla, devuelve el siguiente mensaje de error " lock conflict on no wait transaction", lo cual no sé a que puede ser debido, y me trae loco ya que cada día tengo mas usuarios trabajando en la BD de forma sumiltanea.

¿Podría decirme alguien a que puede ser debido?

Saludos y gracias de antemano.

[kinobi]

Hola,

Posteado originalmente por BECERRA
" lock conflict on no wait transaction"

más que un bloqueo (que también) es un conflicto de actualización. La transacción que hace saltar el error está intentando modificar (actualizar o eliminar) un registro "tocado" por otra transacción. Además, la transacción tiene la opción "NO WAIT", es decir, que no esperará a que un posible bloqueo de otra transacción concurrente se resuelva, simplemente devolverá el mensaje de error.

La situación sólo puede resolverse o bien por un rollback en la primera transacción, en cuyo caso la segunda transacción podrá reintentar la actualización, o por un commit, en este caso obtendrá (inevitablemente) un error de actualización y no podrá (salvo que cierre y abra una nueva transacción) aplicar sus cambios.

Me da la impresión que lo he explicado de mala manera. Tu dirás.

Saludos.

[BECERRA]

Muchas gracias, te he entendido perfectamente, lo que me extraña es que me devuelva ese error cuando actúo sobre diferentes registros.

[kinobi]

Hola,

Posteado originalmente por BECERRA
lo que me extraña es que me devuelva ese error cuando actúo sobre diferentes registros.

¿estás seguro que las transacciones no han "tocado" registros comunes?. Si estás trabajando con transacciones muy largas (temporalmente) es fácil que ocurra.

Saludos.

[BECERRA]

Solucionado he puesto wait en la transaccion y no me lo ha vuelto a hacer.

Gracias.

[Marina]

Cómo hago para poner Wait en la transacción?
Yo estoy usando la conexión a Interbase a través del BDE, e inicio la transacción con StartTransaction y la finalizo con Commit o Rollback, y no encuentro un lugar donde poner el Wait.

Alguien puede ayudarme?

Gracias de antemano


Marina

[kinobi]

Hola,

con el BDE no tienes acceso a los parámetros de la transacción (salvo al nivel de aislamiento).

Saludos.

[Kafu]

Yo estoy intentando prevenir este tipo de problemas. ¿Sabeis si hay algún tipo de acceso a información extra del error? Me explico: ahora en caso de conflicto, la transacción menos espabilada se cancela, pero la única información que ofrezco al usuario es que "Otro usuario" ha grabado el mismo registro a la vez y para sobreescribir hay que volverlo a intentar. No tengo un sistema de usuarios de interbase (el tema de usuarios lo llevo por tablas propias). No sé si hay forma de saber desde qué cliente/puesto se ha lanzado el otro commit. Un saludo,



F.T.G.

[kinobi]

Hola,

lo que yo haría en un caso de conflicto de actualización es:

1.- Guardar la información del registro que quiero actualizar en una zona intermedia (variables, un Record, o un objeto diseñado para el caso).

2.- Refrescaría los datos en el DataSet, ésto puede obligar a cerrar y reabrir la transacción; depende del nivel de aislamiento, si es muy alto (p. ej. Snapshot) es inevitable.

3.- Una vez refrescados los datos, localizaría el registro, editaría los datos del mismo con la información que almacené anteriormente y aplicaría los cambios.

Todo puede llegar a hacerse de manera transparente al usuario o pidiendo las autorizaciones (mendiante cuadros de diálogo) oportunas. Por cierto, estoy suponiendo que no se utilizan actualizaciones en caché.

Respecto a información adicional devuelta por el servidor, hasta la versión 1.0 (Firebird) no, pero en la versión 1.5 (o la 2, ahora no recuerdo bien) se han añadido nuevas variables: un identificador de sesión (conexión) y un identificador de transacción si no recuerdo mal, que tal vez pudiesen ser recuperados en el lado cliente.

Saludos.

[Kafu]

Gracias Kinobi, tomo nota. El tema del identificador de sesión y de transacción me parece muy interesante. ¿Pero cómo accedo a esas variables? voy a mirarlo un poco. Muchas gracias y un saludo,



F.T.G.

[kinobi]

Hola,

los identificadores de sesión y transacción que se van a añadir a Firebird 1.5 son variables accesibles desde el servidor en triggers y procedimientos almacenados. No te puedo comentar más porque ahora estoy utilizando la versión 1.0

Saludos.

[raul_sal]

Estaba leyendo la forma en que administras los bloqueos kinobi y dejame ver si entendi.

1. Intento actualizar el registro
2. Cuando me regresa el error del no wait
3. guardo los datos que quiero actualizar
4 abro y cierro mi IBDataset con otra transaccion (o con la misma?)
5 intento actualizar nuevamente los datos.

S no entendi bien porfavor correjanme, ya que tengo el siguiente problema y me urge pero urge solucionarlo

Tengo una aplicacion corriendo en 5 puestos diferentes es de POS

Esta construida con Delphi
6.0 + IBX + Firebird 1.0.3

Tengo un IBDatabase y un IBTransaction (read_commited, rec_version, wait) asociados a todos mis IBDatasets e IBQuerys

Cuando alguien modifica los datos en una tabla especifica al parecer queda algo abierto se bloquean todas aunque las demas no esten tocando ese registro que puede estar sucediendo.

Gracias