RE: Problemas de concurrencia?

From: "Jorge Romeo" <jromeo(at)samca(dot)com>
To: "Rafael Martinez" <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
Cc: postgres ayuda sql español <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: RE: Problemas de concurrencia?
Date: 2009-09-18 11:01:24
Message-ID: 3BFE4B54139F264587EF9BC8EB40185C065B98F6@samca-nt-12.samca.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Si la consulta falla se lanza una excepción. Esta excepción la tengo controlada, pero de momento sólo hago que me muestre el mensaje de error y continue sin ejecutar el comando. Así es como he pillado por qué pasaba. Si un dato no se inserta por lo que sea, que se lo salte porque en unas centésimas va a llegar otro y por tanto la pérdida de datos no es grande (si pasa sólo muy de vez en cuando, claro). Más adelante me plantearé lo de reintentar o tratar mejor el fallo.

Voy a revisar el programa.

-----Mensaje original-----
De: Rafael Martinez [mailto:r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no]
Enviado el: viernes, 18 de septiembre de 2009 12:37
Para: Jorge Romeo
CC: postgres ayuda sql español
Asunto: Re: [pgsql-es-ayuda] Problemas de concurrencia?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jorge Romeo wrote:
> Hola, Monitorizando un poco más fino, he visto que el primer fallo sí
> que es un intento de inserción con claves duplicadas (vaya ojo
> tienes). La PK que me viola es (n_ae, cod_parque, fecha). (n_ae,
> cod_parque) es único y las fechas siempre separadas al menos unas
> centésimas de segundo. Con la precisión del tipo timestamp no debería
> ser posible que coincidan ¿no?.
>

En una centesima de segundo pueden pasar muchas cosas ;-)

Yo he visto sistemas que llegan a realizar varios inserts justo en el
mismo fragmento de tiempo. En sistemas con procesos en paralelo no es
dificil que esto pueda ocurrir mas a menudo.

> Ahora la pregunta es. ¿Cómo fuerzo que cada consulta sea una
> transacción separada?
>

Todavia no tengo claro si el fallo es una transaccion en la base de
datos que falla por la clave primaria duplicada o un fallo en python
porque el comando mandado a la base de datos falla y retorna una excepcion.

Si como dices, estas seguro que no se crea una transaccion en la base de
datos con BEGIN o autocommit=off, el fallo esta en python.

¿Como maneja tu codigo python que un comando mandado a la base de datos
devuelva un fallo? Supongo que podras comprobar si el comando retorna
'todo ok' o 'error' y en caso de error hacer algo (volver a intentar el
mismo comando con una fecha distinta, o saltar al siguiente y archivar
el fallo para una futura comprobacion)

PD.- Revisa que la clave primaria este definida correctamente. Si el
fallo es que intentas insertar exactamente la misma tupla (clave
primaria + resto de datos en la tupla), no importa mucho ignorar este
fallo cuando ocurra.

Pero si el fallo es que lo que tienes definido como clave primaria
contiene un valor ya registrado, y el resto de los datos en la tupla no
son iguales al resto de datos de la tupla que se ha insertado
previamente, vas a perder los datos del segundo insert si ignoras el
error en python.

- --
Rafael Martinez, <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
Center for Information Technology Services
University of Oslo, Norway

PGP Public Key: http://folk.uio.no/rafael/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQFKs2LXBhuKQurGihQRAsHCAJ4oYSGS4uTy9JCJlvjx4CNC6nqsaQCghw3O
QfDcYJ4Gi+POiwsKo4IWJ/g=
=8gnU
-----END PGP SIGNATURE-----

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Emanuel Calvo Franco 2009-09-18 14:53:47 [Off Topic] Database Machine Oracle
Previous Message Rafael Martinez 2009-09-18 10:37:14 Re: Problemas de concurrencia?