There are times in the development process when you might prefer
to use the dynamic query service rather than the regular Enterprise JavaBean
(EJB) query service (which can be referred to as deployment query).
During testing, for instance, the dynamic query service can be used at application
run time, so you do not have to re-deploy your application.
About this task
Following are common reasons for using the dynamic query service
rather than the regular EJB query service:
- You need to programmatically define a query at application run time, rather
than at deployment.
- You need to return multiple CMP or CMR fields from a query. (Deployment
queries allow only a single element to be specified in the SELECT clause.)
For more information, see the Example:
EJB queries article.
- You want to return a computed expression in the query.
- You want to use value object methods or bean methods in the query statement.
For more information, see Path
expressions.
- You want to interactively test an EJB query during development, but do
not want to repeatedly deploy your application each time you update a finder
or select query.
The dynamic query API is a stateless session bean; using it is
similar to using any other J2EE EJB application bean. You can consult the
API specifications in Reference: Generated API documentation
(the
section for package com.ibm.websphere.ejbquery).
The dynamic query bean
has both a remote and a local interface. If you want to return remote EJB
references from the query, or if the query statement contains remote methods,
you must use the query remote interface:
remote interface = com.ibm.websphere.ejbquery.Query
remote home interface = com.ibm.websphere.ejbquery.QueryHome
If
you want to return local EJB references from the query, or if the query statement
contains local methods, you must use the query local interface:
local interface = com.ibm.websphere.ejbquery.QueryLocal
local home interface = com.ibm.websphere.ejbquery.QueryLocalHome
Because
it uses less application server memory, the local interface ensures better
overall EJB performance than the remote.