Con que componente Zeos puedo hacer Transacciones?

[[Lepe]]

Empezado por eduarcol

La diferencia según lo logre entender es que el commit cierra algo asi como la sesion, mientras que commit retain cierra la transacción pero deja la sesion actual activa. Igual vale para el rollback retain.

Sí, pero añadir que "dejar la sesión abierta", mejor dicho mantener el contexto de la transacción, consume recursos, por ello si vas a realizar una inserción masiva, o usas continuamente commitRetaining la aplicación puede volverse lenta después de trabajar con ella. Lo bueno es que los componentes de acceso (Zeos no los he mirado) normalmente realizan un commit cada cierto tiempo, por lo que puede aliviar el problema.

Creo recordar... y sólo creo, que si haces un commitRetaining los demás usuarios de la red no verán ese registro recien añadido, porque precisamente te guarda el contexto de tu transacción.

Saludos

[[eduarcol]]

Empezado por Lepe

Sí, pero añadir que "dejar la sesión abierta", mejor dicho mantener el contexto de la transacción, consume recursos, por ello si vas a realizar una inserción masiva, o usas continuamente commitRetaining la aplicación puede volverse lenta después de trabajar con ella. Lo bueno es que los componentes de acceso (Zeos no los he mirado) normalmente realizan un commit cada cierto tiempo, por lo que puede aliviar el problema.

Creo recordar... y sólo creo, que si haces un commitRetaining los demás usuarios de la red no verán ese registro recien añadido, porque precisamente te guarda el contexto de tu transacción.

Saludos

yo trabajo con transacciones para grabar documentos, de resto dejo la propiedad autocommit en true, ya que por un registro no hay problemas.

Lo de las inserciones masivas no lo he probado, pero para trabajar con los Zeos es necesario el commit retain ya que no te deja iniciar una nueva transaccion, con respecto a lo de la red, hasta el momento no he tenido ese problema eso si el isolation lo dejo en readcommited.

El unico problema que he encontrado, pero segun he leido es asi que deberia funcionar, es que un generador en un rollback no se restaura y si adelanta el numero.

[[Lepe]]

Empezado por eduarcol

El unico problema que he encontrado, pero segun he leido es asi que deberia funcionar, es que un generador en un rollback no se restaura y si adelanta el numero.

Es normal ya que los generadores se encuentran fuera del control transaccional, de ahí que siempre dé un número distinto aunque haya 1000 transacciones insertando 1 registro, y por consiguiente nunca tengamos un key violation.

[rgstuamigo]

ok Lepe pero que piensas de lo que dice PoliBurro:

OJO, En un entorno multiusuario es un grave error colocar transacciones en los clientes. Lo mejor es dejar que el motor se encargue de ese trabajo.

¿Cual es la razon del error? ¿Por que no se deberia poner transacciones en los clientes en un entorno multiusuario?¿Que es lo mas adecuado entonces?