Consideraciones sobre el rendimiento de las consultas dinámicas
Aunque puede ser útil utilizar una consulta dinámica, hay ocasiones en que puede influir en el rendimiento de la aplicación.
Consideraciones generales sobre el rendimiento
El uso de los elementos siguientes en la consulta dinámica puede repercutir negativamente en el rendimiento de la aplicación:
- Conversores de tipo de datos y métodos Java™
Motivo: En general, las operaciones y los predicados de consulta se convierten en SQL de modo que el servidor de bases de datos pueda llevarlos a cabo. No obstante, si la consulta incluye conversores de base de datos (para la correlación de EJB a RDB, por ejemplo) o métodos Java, los predicados y las operaciones asociados de la consulta deben realizarse en la memoria del servidor de aplicaciones.
- Métodos EJB y criterios que requieren la devolución de referencias EJB
Motivo: Las consultas que incorporan estos elementos desencadenan la activación total de beans EJB en la memoria del servidor de aplicaciones. (La devolución de una lista de campos CMP desde una consulta no provoca la activación de un EJB.)
Al valorar el rendimiento de una aplicación, también debe tener en cuenta que las consultas dinámicas comparten conexiones con el gestor de persistencia. Por consiguiente, una aplicación que incluye una combinación de métodos de búsqueda, navegación CMR y consultas dinámicas se basa en una única conexión compartida entre el gestor de persistencia y el servicio de consultas dinámicas para realizar estas tareas.
Limitación del tamaño de colección de retorno
- Consultas de interfaz remota: La clase QueryIterator de la interfaz remota establece que todos los
resultados de consulta se materialicen en la memoria de servidor de aplicaciones
durante el transcurso de una llamada de método. El cursor o cursores SQL utilizados
para ejecutar la consulta EJB se cierran al finalizar la llamada. Puesto que este
requisito supone un alto riesgo de creación de cuellos de botella en el servidor de bases
de datos, deberá limitar el tamaño de las colecciones de resultados que puedan llegar a
ser muy grandes.
- Consultas de interfaz local: En la mayoría de las situaciones, el objeto QueryLocalIterator
se comporta como un envoltorio alrededor de un cursor SQL. Se controla por demanda y hace que se devuelvan
datos de forma incremental.
Para cada recuperación de registro de la base de
datos, es necesario llamar al método next() en el iterador.
No obstante, el uso de determinadas operaciones en las consultas de interfaz local alteran temporalmente el comportamiento controlado por demanda. En estos casos, los resultados de la consulta se materializan completamente en la memoria como ocurre en las colecciones de resultados de las consultas de interfaz remota. Un ejemplo de un caso de este tipo es el siguiente:
select e.myBusinessMethod( ) from EmpBean e where e.salary < 50000 order by 1 desc
Esta consulta requiere que un método EJB produzca la colección de resultados final. Por consiguiente, el conjunto de datos completo de la base de datos debe devolverse en una colección a la memoria del servidor de aplicaciones, donde puede ejecutarse el método EJB en el conjunto de datos en su totalidad. Por este motivo, las operaciones de consulta de interfaz local que invocan métodos EJB generalmente no están controladas por la demanda. No se puede controlar el tamaño de devolución de la colección para las consultas de este tipo.
Dado que están controladas por demanda, todas las demás consultas de interfaz local le permiten controlar el tamaño de las colecciones de retorno. Puede utilizar una llamada del método close() en el objeto QueryLocalIterator para cerrar el bucle de consulta una vez que se haya obtenido el número deseado de valores de retorno del almacén de datos. De lo contrario, los cursores SQL utilizados para ejecutar la consulta EJB no se cerrarán hasta que el conjunto de resultados completo se acumule en la memoria o hasta que finalice la transacción.