Re: Como trabaja Postgre con Transacciones

Alvaro, si no es molestia, me podrias facilitar la vida dandome un ejemplo
de como lo haces tu.

Gracias.

El día 6/11/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> escribió:
>
> Jaime Sierra Gattorno escribió:
> > Hola lista, soy nuevo en Posgre, siempre he usado MS-SQL, pero tengo la
> > oportunidad de crear un nuevo proyecto de desarrollo de aplicación, voy
> a
> > usar como fron-desk Visual Fox Pro, los usuarios aqui solo usan Windows,
> y
> > ademas es el lenguaje que conozco, tengo varias preguntas:
> >
> > 1.- Se que para bloquear un registro solo comienzo mi actualización de
> datos
> > con BEGIN, y postgre toma la decición (creo),
>
> Pequeña aclaracion, no se llama Postgre sino Postgres.
>
> > ¿Cómo se que se encuentra bloqueado un registro?
> > ¿Cómo saber si se bloqueo la tabla compleata o solo algunos registros?
> > ¿Puedo controlar manualmente cual registro / tabla quiero bloquear ?
>
> Postgres no bloquea registros, sino que usa MVCC. Puedes bloquear
> registros explicitamente, usando SELECT FOR UPDATE (lock exclusivo) o
> SELECT FOR SHARE (lock compartido), en cuyo caso otros SELECT FOR
> UPDATE/SHARE quedaran bloqueados si intentan afectar el mismo registro;
> tambien bloquean UPDATE y DELETE, pero no bloquean SELECT ni INSERT.
>
> (Obviamente dos SELECT FOR SHARE no se bloquean mutuamente)
>
> Tambien puedes bloquear tablas explicitamente usando la sentencia LOCK.
> Tambien se hace implicitamente en algunas ordenes como VACUUM, ALTER
> TABLE, etc. Hay varios niveles de bloqueo, y pueden haber varios
> bloqueadores simultaneamente. Por ej. si haces ALTER TABLE o VACUUM
> FULL entonces no puedes hacer casi ninguna otra cosa, pero si haces
> VACUUM o ANALYZE entonces otros pueden acceder a la tabla sin problemas.
>
> Con respecto a los candados a nivel de registro, lo que se hace al
> modificar (UPDATE) un registro es escribir una version nueva, y dejar la
> antigua sin tocar. Cuando otra sesion quiere acceder (leer) al
> registro, simplemente examina la version antigua y deja la nueva sin
> tocar. De esta manera el escritor no bloquea al lector.
>
> La unica situacion en que se bloquean, ocurre cuando dos sesiones
> quieren modificar el mismo registro. Esto es lo que sucede:
>
> Si una sesion esta modificando un registro y otra sesion quiere
> modificarlo simultaneamente, la segunda sesion se bloquea y lo que
> sucede despues depende del nivel de aislamiento de la segunda
> transaccion y de lo que haga la primera. Hay varios casos. Si la
> segunda transaccion es TRANSACTION ISOLATION LEVEL SERIALIZABLE,
> entonces espera a que termine la primera. Si la primera compromete
> (COMMIT) entonces la segunda sesion se aborta con un error de
> serializacion. Si la primera aborta (ROLLBACK) entonces la segunda
> puede continuar.
>
> Si la segunda transaccion es TRANSACTION ISOLATION LEVEL READ COMMITTED
> entonces la segunda espera que la primera termine, y si la primera
> aborta entonces modifica la version original, de lo contrario busca la
> version nueva y la modifica.
>
>
> Finalmente, hay que aclarar que todos los bloqueos duran desde el
> instante en que se adquieren hasta que termina la transaccion en curso.
> No hay manera de liberar un lock sin cerrar la transaccion.
>
> --
> Alvaro Herrera
> http://www.PlanetPostgreSQL.org/
> "La realidad se compone de muchos sueños, todos ellos diferentes,
> pero en cierto aspecto, parecidos..." (Yo, hablando de sueños eróticos)
>