Re: Control de Concurrencia

On Wed, Aug 03, 2005 at 11:12:15PM +0000, P(at)blo Villad@ wrote:

Hola,

> Ahora Nos Surge El Problema
> De Que Cuando Un Funcionario
> Realiza Algun Cambio Sobre Los
> Datos De Un Empleado Estos Se
> Deben Reflejar Sobre Sus Pagos
> y Descuentos.

Hum, esto significa que si haces un cambio en determinado estado de la
base de datos, este estado tiene que propagarse retroactivamente hacia
otros datos relacionados? Suena como algo enormemente engorroso, y
huele a un diseño algo extravagante. Pero ignoremos ese problema por
ahora.

> Pero Que Puede Pasar Si Antes de
> Que Se Realice Un Cambio De Estos
> Se Realice Un Proceso Contable Y No
> Queden Registrados Los Datos Actuales.

Tampoco acaba de quedarme claro. Supongo que lo que estas diciendo es
que si alguien modifica los datos de un empleado, no se puede ejecutar
ningun proceso contable que involucre a ese empleado. Si es el caso,
entonces supongo que lo que tendrias que hacer es "bloquear" el
empleado. Desde ya me parece una idea un poco mala, pero si realmente
es lo que quieres puedes implementarlo usando el modulo
contrib/userlock.

> Que Me Pueden Recomendar Para El
> Control De Versiones Concurrentes.

Mira la presentacion "Transaction Processing in PostgreSQL" de Tom Lane,
en www.postgresql.org/docs

> Lo Que he podido leer es:
>
> Read Committed Isolation Level
> Serializable Isolation Level
>
> Pero la verdad no me quedan muy
> claras las cosas..

Hmm, supongo que si no tienes claros esos dos conceptos lo que te
conviene es echarle un vistazo a algun libro que los explique.

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"XML!" Exclaimed C++. "What are you doing here? You're not a programming
language."
"Tell that to the people who use me," said XML.