Cita:
|
Empezado por rastafarey
La mayoria d elos problemas suceden cuando se trata de hacer modificaciones a registrso que han sido modificacoados y no se le han notificados al resto de los clientes para que se actualicen lo cual produciria bloques muertos.
|
negativo!
Cita:
|
Empezado por rastafarey
Como ib/firebird usan versionado d e regsitros por defecto los clientes modifcan un a copis dle mismo y con esto es que hay que tenr cuidado por lso registrso no s ebloquen como otros manejadores(si mas no recuerdo ib/fb es le unico que usa esto)
|
Amigo rastafarey, lamento informarte que estas equivocado. Interbase/Firebird efectivamente pueden mantener diferentes versiones de los registros para las transacciones de lectura, pero una vez el registro ha sido actualizado, ninguna otra transacción podrá modificarlo de nuevo.
No existe tal cosa como la "notificación al resto de los clientes para que se actualicen". Supongo que te referís a que un cliente, al leer de nuevo el registro obtenga una copia "fresca" de este. Esto está gobernado por el nivel de aislamiento de la transacción. Si tenes una transacción con nivel de aislamiento Read Commited, obtendrá la última versión confirmada cada vez que se haga un fetch del registro. Por el contrario, una transacción serializable obtendrá siempre la misma versión del registro, independientemente de cuantas veces haya sido este actualizado, una característica que la arquitectura multigeneracional de estos motores hace parecer sencilla y natural, y que tiene increibles costos de rendimiento para otros motores que te ofrezcan transacciones serializables, mientras que la mayoría simplemente no puede ofrecerlas.
Cuando un registro ha sido actualizado, se coloca un bloqueo sobre este, de manera que ninguna otra transacción podrá modificarlo hasta que el bloqueo sea liberado (mediante un commit o un rollback), y dichas modificaciones las hace el servidor y solo el servidor. No existe tal cosa como que cada cliente modificará sus propias copias...
Hasta luego.
