Ver Mensaje Individual
  #13  
Antiguo 30-09-2012
rolandoj rolandoj is offline
Miembro
 
Registrado: abr 2007
Posts: 395
Reputación: 18
rolandoj Va por buen camino
Nuevos comentarios

Cita:
Empezado por Casimiro Notevi Ver Mensaje
El commitRetaining confirma la transacción, se guardan en la BD los datos, pero no cierra la transacción sino que la mantiene activa, por lo que el dataset se queda abierto para que se pueda hacer nuevos cambios con la misma transacción.
Hola Casimiro,

Bueno, según mi traducción, conceptualmente ese punto no es exactamente así; aunque para efectos prácticos es más o menos lo mismo.

Para ser claros, yo entiendo es que, en el caso de transacciones explícitas (que es siempre mi caso), las tecnologías de acceso (como BDE, dbExpress, etc), usualmente emiten un Commit normal que cierra la transacción y libera enseguida los recursos asociados. Eso es lo que yo hecho toda la vida.

Sin embargo, el método Commit de Zeos no emite un commit normal sino un comando "Commit Retaining" el cual hace básicamente lo mismo; pero, no libera los recursos. Es decir; si cierra la transacción. Lo que pasa es que inmediatamente abre una nueva transacción para la cual los recursos que se usaron en la anterior están "vivos", o sea utilizables en esta nueva.

En Zeos, según dicen ahí, el commit normal no se ejecuta a voluntad con un método propio, sino que es efectuado automáticamente cuando se cierra no una tranascción sino una conexión a la Base de Datos.

Por eso es que la interpretación que hice al inicio fué que, para optimizar ese aspecto, tocaba tener una sola transacción por connexión. En otras palabras, que una vez hecho Connected a True se debe llamar a StarTransaction, y tan pronto se haga el Commit (o el Rollback) poner Connected a False.

Por ende, dado que eso implica perder el cache de la conexión, pregunté si había estudios que sugieren que era mejor de hacerse (o si daba lo mismo), entre perder rendimiento usando múltiples transacciones por conexión, o perder el caché de conexión usando una transacción por conexión.

Vale anotar algo para los que tengan problemas de tradución del original. El modo autocommit es el modo de default del componente de conexión a la Base de Datos de Zeos (o sea TZConnection). En el modo autocommit, cada operación sencilla (Insert, update, etc) es implícitamente una única transaction.

En la práctica, no debería trabajarse nunca con este modo, a menos que se sepa que se va a actualizar un registro cuyos cambios no afectan a ningún otro registro de ninguna tabla de la Base de Datos. De lo contrario, sería frecuente que aparecieran datos inconsistente.

En lugar de eso, debería usarse el modo explícito; el cual es invocado por StarTransaction, invocación que por supuesto apaga el autocommit. Eso si, debe tenerse en cuenta que cuando la transacción explícita termina, también se reactiva automáticamente el modo autocommit.
Responder Con Cita