Cómo parar la Máquina Virtual Java (Aurora)

Recibo un ‘mail’ del departamento de ‘TEST’ en el que se me dice que ciertas ‘queries’ tardan mucho en ejecutarse. Se da la circunstancia que todas ellas utilizan procedimientos almacenados java (‘java stored procedures’). La solución al enigma está clara: la primera vez que se ejecutan estos procedimientos sus clases java subyacentes deben cargarse y resolverse en la Máquina Virtual Java (‘Java Virtual Machine’), la famosa ‘Aurora’. Este tema es conocido: la JVM debe primero cargar las clases y más tarde traducir los ‘bytecodes’ para su ejecución (en otras máquinas virtuales hay una segunda compilación que traduce los ‘bytecodes’ a código nativo, esto lo hacen los compiladores ‘just in time’, pero Oracle carece de ellos, por lo que el java es siempre interpretado a no ser que se utilice jAccelerator/NCOMP).

La primera pregunta es: ¿ocurre esto una sola vez o en cambio ocurre una vez por sesión? Y la respuesta es: una sola vez. Sea cual sea la sesión que invoque los procedimientos almacenados java, estos quedan ya resueltos en la Máquina Virtual Java y subsiguientes llamadas desde otras sesiones no incurren en el retardo.

Esto me hace preguntarme cómo puedo limpiar todo el código java cargado para poder así hacer pruebas del tiempo que tardan las famosas ‘queries’ la primera vez que son invocados los procedimientos almacenados java (que en realidad son métodos de las clases subyacentes).

Por supuesto, algo como:

sys@xxxxxxx.yyyyyyy> ALTER SYSTEM FLUSH JAVA_POOL;

sería lo idóneo, pero desafortunadamente no existe.

Después de bucear el las diferentes documentaciones (Metalink incluido) descubro referencias a DBMS_JAVA. Este paquete está pobremente documentado, parece ser que a propósito. No obstante, aparecen tres procedimientos que parecen prometedores: AURORA_SHUTDOWN, SERVER_SHUTDOWN y SERVER_STARTUP. También descubro referencias sobre ellos en ‘system triggers’ que se generan en las instalaciones básicas: los ‘system triggers’ son ‘AFTER STARTUP ON DATABASE’ y ‘BEFORE SHUTDOWN ON DATABASE’.

‘Ya está’, pienso. ‘Estos procedimientos permiten arrancar y parar la Máquina Virtual Java’. Así que ejecuto:

sys@xxxxxxx.yyyyyyy> EXEC DBMS_JAVA.SERVER_SHUTDOWN;

Procedimiento PL/SQL terminado correctamente.

Y me voy a otras sesiones a esperar el fallo de las ‘queries’ en cuestión… para encontrar que las ‘queries’ siguen funcionando como si tal cosa. Con lo que de ‘SERVER_SHUTDOWN’, nada. Pero nada de nada.

Y lo mismo ocurre con DBMS_JAVA.AURORA_SHUTDOWN.

En resumen: la única forma de limpiar todo el java para hacer pruebas de lo que tardan en cargarse y compilarse las clases java en la primera llamada a uno de sus métodos es…

sys@xxxxxxx.yyyyyyy> STARTUP FORCE

O esa es la conclusión a la que he llegado. Que alguien me corrija si no es así…

Saludos.

Carlos.

2 respuestas a Cómo parar la Máquina Virtual Java (Aurora)

  1. Oscar Juarez dice:

    Hola, sabes que con respecto a java y lo que comentas de que solo la primera vez que se ejecuta independientemente de la sesion, me dejaste con la duda, ya que nosotros tenemos algunos procesos que invocan clases java para realizar ciertas tareas y la primera vez que se ejecuta en cada sesion, se tarda alrededor de 7 u 8 segundos, y dentro de la misma sesion las ejecuciones posteriores se tardan solo 2. Y en cada sesion repito el proceso y el patron se repite…

  2. carlosal dice:

    Óscar:

    ¿Estás seguro de que el retardo es sólo por las clases java? Los ‘packages’ se deben cargar, esos sí, para cada sesión.

    Saludos.

    Carlos.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: