Ver Mensaje Individual
  #5  
Antiguo 27-09-2012
rolandoj rolandoj is offline
Miembro
 
Registrado: abr 2007
Posts: 395
Reputación: 18
rolandoj Va por buen camino
Comentarios

Hola Casimiro,

Cuando hablaba de limpieza automática me refería sobretodo a los registros inservibles que tuvieron vida durante la transacción. Según lo que leí, al usar el método Commit de Zeos ellos no se limpian automáticamente. Para que se de la operación de limpieza hay que cerrar la conexión.

Ciertamente, el modelo Web, basado en librerías (otra cosa serían los ejecutables CGI), parte de que esas librerías permanecen en memoria, a fin de optimizar el acceso a las mismas.

Cuando pasado algún tiempo, configurable en el sistema, esas librerías, que están en memoria, no han recibido nuevas peticiones, el servidor Web las descarga de la memoria, operación que, lógicamente, cierra la conexión a la Base de Datos.

En el entorno más común, eso significa que en la práctica hay al menos una descarga de memoria al día. Sin embargo, en empresas que tengan producción de 24 horas, y/o operaciones con países de un uso horario distinto, es posible, dependiendo de la frecuencia de las operaciones, que pasen días o incluso semanas, sin que se descarguen las librerías. Son entornos en los que se hace necesario un frecuente manteniemiento programado.

Si las susodichas empresas tiene altos volumenes de operación, es claro que el rendimiento se degradaría más rápido.

De ahí mi pregunta, porque el tema sería de estadísticas : Hay estudios que confronten esa penalidad vs la penalidad de estar abriendo y cerrando la conexión por cada transacción.

Ten en cuenta que el modelo Web, que yo manejo, no opera como trabaja la mayoría de la gente. Todo el control transaccional existe solo en el servidor. El cliente no sabe nada de la base de datos y menos de transacciones.

Cada petición del cliente al servidor, si contiene alguna adición, modificación o borrado de datos. se hace en una sola transacción. Por lo anterior, en mi caso, adoptar el esquema de una conexión por transacción es programáticamente trivial, algo de minutos.

La razón es que solo tendría que modificar la macrorutina que responde a cada petición para abrir la conexión a la base de datos, hacer las tareas que hacía antes y cerrar la conexión al terminar.

En otras palabras, reubicar la apertura de la conexión, que actualmente hago a la carga de la librería, y el cerrado (actualmente en el descargue de la librería), para ponerlos en la macrorutina.

El problema pués no es de dificultad de programación sino de rendimientos. Hay que ver si se consigue mayor información
Responder Con Cita