Para habilitar el log JDBC se deben modificar los siguientes parámetros:
|
Parámetro |
Descripción |
Ejemplo |
|
JDBC_LOG |
Ruta donde se almacenará el log. El usuario que ejecuta el servlet container (por ejemplo, Tomcat) debe tener permisos de escritura en ese directorio. |
JDBC_LOG=c:\gxporajdbc.log |
|
JDBCLogEnabled |
Indica si el log está habilitado.
1 = Habilitado
0 = Deshabilitado |
JDBCLogEnabled=1 |
Adicionalmente, se debe reemplazar el archivo WEB-INF\lib\gxclassr.jar por WEB-INF\lib\gxclassd.jar (este último se puede obtener contactándose con el área de soporte).
Caching
Para mejorar los tiempos de respuesta de los sitios web es posible habilitar el caché de tablas en el frontend de GXportal.
Existen 3 niveles de caché posibles, de acuerdo a la frecuencia de actualización de las tablas. Para cada nivel se indica el tiempo en minutos que las tablas estarán en el caché (0 no se cachean, -1 se cachean indefinidamente). Las tablas de GXportal están distribuidas en estos 3 niveles de caché.
|
Parámetro |
Descripción |
Ejemplo |
|
CACHING |
Indica si el caché está habilitado.
1 = Habilitado
0 = Deshabilitado |
CACHING=1 |
|
CACHE_TTL_0 |
Tiempo que las tablas que se actualizan con frecuencia estarán en el caché |
CACHE_TTL_0=0 |
|
CACHE_TTL_1 |
Tiempo que las tablas que se actualizan de vez en cuando estarán en el caché |
CACHE_TTL_1=60 |
|
CACHE_TTL_2 |
Tiempo que las tablas que se actualizan muy poco estarán en el caché |
CACHE_TTL_2=600 |
|
CACHE_TTL_3 |
Tiempo que las tablas que se actualizan casi nunca estarán en el caché (0 no se cachean, -1 se cachean indefinidamente) |
CACHE_TTL_3=-1 |
|
CACHE_STORAGE_SIZE |
Espacio de memoria, en KB, que ocupa el caché (0 es ilimitado) |
CACHE_STORAGE_SIZE=0 |
Importante: El caché no debe habilitarse en el backend. Si se habilita en el backend pueden ocurrir serios problemas de funcionamiento.
Archivos temporales
Para la subida y descarga de archivos asociados a contenidos y para la subida de imágenes GXportal guarda temporalmente los archivos en directorios.
El usuario con el que ejecuta el servlet container (por ejemplo, Tomcat) debe tener permisos de escritura sobre estos directorios.
|
Parámetro |
Descripción |
Ejemplo |
|
CS_BLOB_PATH |
Directorio temporal para archivos almacenados dentro de la base de datos |
CS_BLOB_PATH=/home/gxportal/gxptmp |
|
TMPMEDIA_DIR |
Directorio temporal para subida de imágenes |
TMPMEDIA_DIR=/home/gxportal/gxptmp |
Pool de conexiones
Es posible modificar los parámetros del pool de conexiones a la base de datos. Los parámetros disponibles se encuentran dentro de la sección “DEFAULT” y son los siguientes:
|
Parámetro |
Descripción |
Ejemplo |
|
PoolROEnabled |
Indica si el pool read only está habilitado.
1 = Habilitado
0 = Deshabilitado |
PoolROEnabled=1 |
|
PoolRWEnabled |
Indica si el pool read/write está habilitado.
1 = Habilitado
0 = Deshabilitado |
PoolRWEnabled=1 |
|
UnlimitedRWPool |
Indica si el pool read/write puede tener una cantidad ilimitada de conexiones.
1 = Ilimitado
0 = Limitado |
UnlimitedRWPool=1 |
|
POOLSIZE_RW |
Indica la cantidad máxima de conexiones que pueden haber en el pool read/write |
POOLSIZE_RW=10 |
|
RecycleRW |
Con esta propiedad podemos especificar si se van a reciclar las conexiones a la base de datos en el pool read/write. Esta propiedad tiene como objetivo cerrar las conexiones que están sin ser utilizadas por determinado tiempo, siempre y cuando la conexión esté en un estado “desconectable”, sin “commits” pendientes, ni cursores abiertos.
1 = Reciclar conexiones
0 = No reciclar conexiones |
RecycleRW=1 |
|
RecycleRWMin |
Si se selecciona que las conexiones se reciclen, se debe indicar en esta propiedad cuánto tiempo (en minutos) puede estar disponible una conexión en estado desconectable antes de ser destruida. |
RecycleRWMin=30 |