[Javier Ader]

Buenas. Esto no se si es un error, en realidad tal vez pasaba en la versión anterior y no daba problemas (la verdad que no lo probé); tambien, nunca me habia puesto a mirar antes estos datos, asi que tal vez se “normal”.
Hice esto:
-migre a 11.05 (ayer esto, cerre y volvi a loguearme hoy)
-entre a ventas-> TPV. Cree un factura, y di en cobrar
-me tiro error de libro de caja abierto
-me loqueo (sin cerrar la instancia anterior) en Administracion y completo un libro anterior (antes tuve que modificar los “Dias de Historia”, porque aca ahora me tiro el error de periodo cerrado)
-reintento a compleción de del libro. Ok
-vuelvo al tpv y cobro-> ok

Ahora bien, se me da por mirar en pgAdmin el estatus del server (que muestra las conexiones exsitentes y la transacciones mantenidas); tambien muestra los locks mantenidos. Me aparecia una conexión con una transaccion en curo y algunos locks…. era raro poruqe supuestamente ya habia termindo todo. Cierro la instancia logueada en Administracion; sigue igual. Cierro el tpv…Sigue igual. Me puse a investigar un poco para saber que locks sobre que objetos estaban dados.
Un simple “select * pg_locks” da esta info, pero no es muy clara. Asi que llego a la sig. query:

Code:

select d.datname,
c.relname, c.relkind,
CASE
when c.relkind = ‘r’ THEN ‘table’
when c.relkind = ‘i’ THEN ‘index’
when c.relkind = ‘S’ THEN ‘sequence’
when c.relkind = ‘v’ THEN ‘view’
ELSE ‘other’
END as nameRelKind,

l.mode,l.granted,l.pid,
* from pg_locks l
left join pg_database d on (d.oid = l.database)
left join pg_class c on (c.oid = l.relation)

Me retorno (con mas columnas, pongo las que creo importantes):

Code:

“cog1009v1″;”pg_locks”;”v”;”view”;”AccessShareLock”;t;568;”relation”
“cog1009v1″;”ad_sequence_name”;”i”;”index”;”AccessShareLock”;t;3780;”relation”
““;”“;”“;”other”;”ExclusiveLock”;t;568;”virtualxid”
““;”pg_database_oid_index”;”i”;”index”;”AccessShareLock”;t;568;”relation”
“cog1009v1″;”pg_class_oid_index”;”i”;”index”;”AccessShareLock”;t;568;”relation”
““;”pg_database_datname_index”;”i”;”index”;”AccessShareLock”;t;568;”relation”
““;”“;”“;”other”;”ExclusiveLock”;t;3780;”virtualxid”
“cog1009v1″;”ad_sequence”;”r”;”table”;”AccessShareLock”;t;3780;”relation”
“cog1009v1″;”pg_class_relname_nsp_index”;”i”;”index”;”AccessShareLock”;t;568;”relation”
“cog1009v1″;”ad_sequence_key”;”i”;”index”;”AccessShareLock”;t;3780;”relation”
“cog1009v1″;”pg_class”;”r”;”table”;”AccessShareLock”;t;568;”relation”
““;”pg_database”;”r”;”table”;”AccessShareLock”;t;568;”relation”
“cog1009v1″;”ad_sequence_name2″;”i”;”index”;”AccessShareLock”;t;3780;”relation”

Adjunto un screen por si no se entiende.

[attachment=146]lock-basededato-lib11.05.JPG[/attachment]

Ok. Ahi se estan manteniendo un lock de acceso compartido sobre la tabla ad_sequence (e indices de la misma), por lo tanto dentro de una transacción (o al menos así parece; la columna trxId me da null, pero me parece que se da muestran de otra manera las transaccion que genera libertya) ; el mismo “cliente” con pid 3780 (el pid , en realidad es el del thread de postgres que esta sirviendo una determinada conexion a un cliente; los locks los mantienen estos procesos de lado del servidor), tambien mantiene un lock de acceso exclusivo sobre otro objeto que no se muy bien que es. El tema de ad_sequence me da la sensacion que viene por completar documentos (que usan esta tabla para los num. de doc); yo habia fallado en completar documentos en los pasos que lleve aca (tanto desde el tpv, como al completar el libro de caja)… mi “temor” es que este locks no liberado venga por ese lado.

Bueno, mucho más no investigue por ahora, y la verdad que tal vez es el funcionamiento correcto. Lo planteo por las dudas.

PD: un lock compartido no liberado tal vez no afecte la correctitud, pero muy probablemente sí la performance.

[Javier Ader]

Bueno, no avance mucho mas en el análisis; solo agrego que cerre el cliente (el que ejecuto el TPV) y el lock sobre ad_sequence desapareció (e.d, lo había tomado via TPV seguramente). Entre de nuevo, y complete otra factura desde el TPV, esta vez sin error (el libro de caja ya estaba abierto), pero esta vez no estaba ni lock ni la transacción sobre ad_sequence; esto es, al parecer bajo situacion “normal” (sin error al intentar completar un documento), no parece quedar este lock.

[Federico Cristina]

Javier,

Gracias por el dato. Lo estaremos revisando a la brevedad dado que este es un tema de suma importancia para nosotros. Probablemente sea una omisión en la lógica de las nuevas ampliaciones realizadas en el TPV.

Saludos,
Federico

[Javier Ader]

De nada. Ahí probé de nuevo (sin cerra la caja anterior, así fallaba), haciendolo fallar varias veces; el primer fallo no tomo el lock; pero los siguientes si… aun mas, ahora me aparecen locks sobre c_bpartner (pero no siempre…); sobre ad_sequence solo me aparecio un solo lock. Tal vez este comportamiento medio “errante” se deba a que hay alguna cache, pero sigo sin saber bien…
TPV para en la linea 1466 de PoSOnline: throwIfFalse(cash.getC_Cash_ID() > 0); pero el error se genera la linea 1463: cash = MCash.get(…..) (falla en el beforeSave de MCash, y posiblemente antes de volver PosOnline, la transacción ya este rollbakeada… pero tampoco estoy muy seguro).

Lo que si, ante cada fallo que genera un lock no liberado, quedan conexiones TCP también colgadas (esto es, abiertas pero sin uso; despues de 3 o 4 fallos el cliente tenia 11 conexiones tcp al servidor).

PD: otra cosa que también es posible es que haya un bug en el server que uso o en la versión del driver JDBC; tal vez bajo ciertas condiciones no se hacen roolbacks de manera completa y quedan un par de locks dando vueltas.

[Javier Ader]

Buenas. Sigo sin saber porque ocurre esto realmente, pero mirando los log de PostgreSQL la tabla
AD_Sequence es accedida usando un select de la forma (y solo a esta tabla)

Code:

SELECT ….. FROM AD_Sequence
FOR UPDATE

Ese FOR UPDATE me parece que es la clave; en realidad creo recordar haber visto sistemas basados en compiere evitaban este modificador (por alguna razón…) cuando el servidor era PostGreSQL; como si este FOR UPDATE funcionase como era esperado bajo Oracle, no así sobre PostGreSql. Después investigo un poco más.

PD: el lock sobre C_Bpartner nuevo debe venir por otro lado…. no creo que se lo acceda esta tabla con un FOR UPDATE en algún punto del sistema, pero uno nunca sabe….

[Autor]

Entradas