Entendí tu pregunta.
Creo que no me entendiste la respuesta.
Postgresql no es como Oracle ( Oracle soporta basicamente dos tipos de
modos transaccionales ), postgresql 4 ( de lo que recuerdo ).
En los links que te envie. una persona tiene un problema similar al que
tu tienes.
Puedes revisar lo que envie por favor.
http://dba.stackexchange.com/questions/62024/how-to-set-isolation-to-serializable-deferrable-for-a-whole-postgresql-database
revisa si tienes esta opcion por favor.
transaction_deferrable = on.
Lo pregunto por que me tinca que alguien cambio algunas cosas para que
la base de datos sea más rápida ( pero eso te genera otro otros
problemas de consistencia ).
Ahora si estas usando pool, revisa que estes realmente conectado al
master y no al esclavo, ( de hecho yo probaría con el esclavo abajo ).
Algo esta mostrando datos sucios ( dirty read ).
Lo otro que puede estar afectando es que un componente este conectado al
pool y el otro a la base de datos de forma directa, ( imagino que el
pool tiene algun delay para tener velocidad ) pero esto es pura conjetura.
On 19/05/2016 10:16 PM, Ruben Fitó wrote:
jajajaj, como siempre me explico fatal.
Expongo un mini esquema del pipeline:
*BACKEND WEB (JAVA-JDBC)
* *Aplicación en C* *Anotaciones*
Tiene varias conexiones permanentes
Inicia un bloque transaccional con BEGIN
Inicia una petición SOAP
Inicia proceso de la petición del backend
Abre una nueva conexión con la base de datos Libreia libpq
Hace un INSERT sin (BEGIN). Pqexec() + Pqclear() Hemos
comprobado que
la fila se inserta. Por lo tanto el autocommit hace su función. Lo que
no sabemos es si es instantáneo.
La base de datos le devuelve el valor del ID de la fila. El ID
es un
serial.
Cierra la conexión con la base de datos.
Devuelve el ID al backend
Con el ID hace una busqueda en la misma tabla
Postgres responde que no encuentra la fila
Si incluimos un sleep(1) antes de ejecutar la query
SI que la encuentra. Vaya añadimos un lag de un segundo.
Como pueden ver son conexiones diferentes, bloques transaccionales
diferentes, programas diferentes.
Por lo tanto cuando el backend hace la consulta debería encontrar la fila.
Hemos intentado simular este mismo pipeline manualmente desde
psql/scripts y no hemos podido reproducir esta situación.
Podría incluir que el backend hace un rollback si NO encuentra la fila y
un commit si la encuentra, pero creo que esto es irrelevante para este caso.
Espero se entienda. jejeje
Un fuerte saludo
2016-05-19 10:35 GMT+02:00 Eduardo Morras <emorr...@yahoo.es
<mailto:emorr...@yahoo.es>>:
Resumiendo si lo he entendido bien:
Transaccion A
BEGIN
BEGIN
INSERT
AUTOCOMMIT
BEGIN
INSERT
AUTOCOMMIT
BEGIN
INSERT
AUTOCOMMIT
....
No hay COMMIT para el BEGIN inicial
Al hacer un SELECT no puedes leer los datos guardados ya que no han
sido realmente guardados.
Que es lo que quieres hacer? Que permanezcan los datos en la BD? Haz
el COMMIT final. Que no permanezca pero poder consultarlos? Define
la tabla para que pueda ser leida por readers y haz un ROLLBACK al
final, si no son muchos datos es mas rapido que crear una tabla
temporal y hacerle un drop posterior.
--
*Ruben Fitó *
Software Engineer
Ubiquat Technologies, SL
r.f...@ubiquat.com <mailto:j.catari...@ubiquat.com>
www.ubiquat.com <http://www.ubiquat.com/>
Tota la informació continguda en aquest document i arxius adjunts és
CONFIDENCIAL protegida per llei de secret comercial. Si l'ha rebut per
error, si us plau elimini'l i posi's en contacte amb l'emissor.
All information contained in this document and any attachments are
CONFIDENTIAL and protected under trade secret laws. If you receive this
message by mistake, please delete it and notify it immediately to the
sender.
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
