111 Using Advanced Query API

111.1.1 How to Create a Redirect Query

To perform complex operations, you can combine query redirectors with the TopLink query framework. To create a redirector, implement the oracle.toplink.queryframework.QueryRedirector interface. The query mechanism executes the Object invokeQuery(DatabaseQuery query, Record arguments, Session session) method and waits for the results.

TopLink provides one preimplemented redirector, the MethodBasedQueryRedirector method. To use this redirector, create a static invoke method on a class, and use the setMethodName(String) call to specify the method to invoke.

ReadObjectQuery query = new ReadObjectQuery(Employee.class);
query.setName("findEmployeeByAnEmployee");
query.addArgument("employee");

MethodBaseQueryRedirector redirector = new
     MethodBaseQueryRedirector(QueryRedirectorTest.class, "findEmployeeByAnEmployee");
query.setRedirector(redirector);
Descriptor descriptor = getSession().getDescriptor(query.getReferenceClass());
descriptor.getQueryManager().addQuery(query.getName(), query);

Vector arguments = new Vector();
arguments.addElement(employee);
objectFromDatabase = 
    getSession().executeQuery("findEmployeeByAnEmployee", Employee.class, arguments);

public class QueryRedirectorTest {

    public static Object findEmployeeByAnEmployee(
                                 DatabaseQuery query,
                                 oracle.toplink.sessions.Record arguments,
                                 oracle.toplink.sessions.Session
                                 session) {
        ((ReadObjectQuery) query).setSelectionObject(arguments.get("employee"));
        return session.executeQuery(query);
    }
}

111.3.1 How to Configure Default Fetch Group Behavior

You can optionally designate at most one fetch group as the default fetch group for a descriptor's reference class.

If you execute a ReadObjectQuery or ReadAllQuery without specifying a fetch group, TopLink will use the default fetch group unless you configure the query otherwise, as Example 111-3 shows.

// at the descriptor level
FetchGroup group = new FetchGroup("nameOnly");
group.addAttribute("firstName");
group.addAttribute("lastName");
employeeDescriptor.getFetchGroupManager().addFetchGroup(group);
// set the default fetch group
employeeDescriptor.getFetchGroupManager().setDefaultFetchGroup(group);

// when query1 is executed, the default fetch group applies
ReadAllQuery query1 = new ReadAllQuery(Employee.class);

// when query2 is executed, the default fetch group does not apply
ReadAllQuery query2 = new ReadAllQuery(Employee.class);
query2.setShouldUsedefaultFetchGroup(false);

111.3.2 How to Query with a Static Fetch Group

Example 111-4 shows how to configure a ReadObjectQuery for the Employee class with a FetchGroup named nameOnly previously stored in the FetchGroupManager owned by the Employee class's descriptor.

// create static fetch group at the descriptor level
FetchGroup group = new FetchGroup("nameOnly");
group.addAttribute("firstName");
group.addAttribute("lastName");
descriptor.getFetchGroupManager().addFetchGroup(group);

// use static fetch group at query level
ReadAllQuery query = new ReadAllQuery(Employee.class);
query.setFetchGroupName("nameOnly");

111.3.3 How to Query with a Dynamic Fetch Group

Example 111-5 shows how to create a FetchGroup instance dynamically, at the time you create and execute a query, and configure the query with that FetchGroup directly.

In this example, only the firstName, lastName, and salary attributes are fetched. If you call the Employee method get for any other attribute, TopLink executes another query to retrieve all unfetched attribute values. Thereafter, calling that get method will return the value directly from the object.

// dynamic fetch group query
ReadAllQuery query = new ReadAllQuery(Employee.class);
FetchGroup group = new FetchGroup("nameAndSalary");
group.addAttribute("firstName");
group.addAttribute("lastName");
group.addAttribute("salary");
query. setFetchGroup(group);

111.7.1 How to Append Additional Join Expressions Using Java

Using Java, configure a descriptor with additional join expressions by creating an amendment method (see Section 119.35, "Configuring Amendment Methods"), and then using the DescriptorQueryManager methods setAdditionalJoinExpression or setMultipleTableJoinExpression, as Example 111-7 shows.

public static void addToDescriptor(Descriptor descriptor) {
    ExpressionBuilder builder = new ExpressionBuilder();
    descriptor.getQueryManager().setAdditionalJoinExpression(
        (builder.getField("EMP.STATUS").notEqual("DELETED")).and(
             builder.getField("EMP.STATUS").notEqual("HISTORICAL"))
    );
}

111.9.1 How to Use Oracle Hints

Oracle Hints is Oracle Database feature through which you can make decisions usually reserved for the optimizer. You use hints to specify things such as join order for a join statement, or the optimization approach of an SQL call.

The TopLink query framework supports Oracle Hints with the following API:

setHintString("/*[hints or comments]*/");

TopLink adds the hint to the SQL string as a comment immediately following a SELECT, UPDATE, INSERT, or DELETE statement.

Add hints to a read query as follows:

1. Create a ReadObjectQuery or a ReadAllQuery

2. Set the selection criteria.

3. Add hints as needed.

For example, the following code uses the FULL hint (which explicitly chooses a full table scan for the specified table):

// Create the query and set Employee as its reference class
ReadObjectQuery query = new ReadObjectQuery(Employee.class);
// Retrieve ExpressionBuilder from the query
ExpressionBuilder builder = query.getExpressionBuilder();
query.setSelectionCritera(builder.get("id").equal(new Integer(1));
// Add the hint
query.setHintString("/*+ FULL */" ); 

This code generates the following SQL:

SELECT /*+ FULL */ FROM EMPLOYEE WHERE ID=1

To add hints to WRITE, INSERT, UPDATE, and DELETE, create custom queries for these operations in the TopLink query framework, then specify hints as required. For more information, see the following:

• Section 23.4, "Configuring Custom SQL Queries for Basic Persistence Operations"

• Section 76.5, "Configuring Custom EIS Interactions for Basic Persistence Operations"

For more information about the available hints, see Oracle Database documentation.

111.9.2 How to Use Hierarchical Queries

Hierarchical Queries is Oracle Database mechanism that lets you select database rows based on hierarchical order. For example, you can design a query that reads the row of a given employee, followed by the rows of people this employee manages, followed by their managed employees, and so on.

To create a hierarchical query, use the setHierarchicalQueryClause method. This method takes three parameters, as follows:

setHierarchicalQueryClause(startWith, connectBy, orderSibling)

This expression requires all three parameters, as described in the subsequent text.

ReadAllQuery raq = new ReadAllQuery(Employee.class);
// Specifies a START WITH expression
Expression startExpr = expressionBuilder.get("id").equal(new Integer(1));
// Specifies a CONNECT BY expression
Expression connectBy = expressionBuilder.get("managedEmployees");
// Specifies an ORDER SIBLINGS BY vector
Vector order = new Vector();
order.addElement(expressionBuilder.get("lastName"));
order.addElement(expressionBuilder.get("firstName"));
raq.setHierarchicalQueryClause(startExpr, connectBy, order);
Vector employees = uow.executeQuery(raq);

SELECT * FROM EMPLOYEE START WITH ID=1 CONNECT BY PRIOR ID=MANAGER_ID ORDER SIBLINGS BY LAST_NAME, FIRST_NAME

111.10.1 How to Create a Finder

In general, to create a finder for an entity bean that uses the TopLink query framework, you must define, declare, and configure it.

For predefined finders (see Section 108.15.1, "Predefined Finders"), you do not need to explicitly create a finder.

For default finders (see Section 108.15.2, "Default Finders"), you only need to define the finder method.

To create a finder for an entity bean that uses the TopLink query framework, follow these steps:

1. Define the finder method on the entity bean's remoteHome or localHome interface.

   For entity beans with container-managed persistence, define the method on the entity bean's Home interface.

   For default finders (see Section 108.15.2, "Default Finders"), you must define the finder as follows:

   • <RETURN-TYPE> findBy<CMP-FIELD-NAME>(<CMP-FIELD-TYPE>)

   • the first letter of <CMP-FIELD-NAME> must be capitalized

   • <RETURN-TYPE> may be a single bean type or Collection.

   For example:

   EmployeeBean (Integer id, String name)
   EmployeeHome ..{
      Employee findById(Integer id) throws...;
      Collection findByName(String name) throws...;
   } 
   

   Note:

   If you are using default finders (see Section 108.15.2, "Default Finders"), you are finished. TopLink will implement the finder for you at run time.

2. Declare the finder in the ejb-jar.xml file (see Section 111.10.1.1, "ejb-jar.xml Finder Options").

3. Start TopLink Workbench.

4. Click the project icon in the Navigator and select: Selected > Update Project from ejb-jar.xml to read in the finders.

5. Go to the Queries > Named Queries tab for the bean (see Section 109.3, "Using Named Queries").

6. Select and configure the finder.

   Notes:

   For predefined finders findOneByQuery and findManyByQuery, the client creates a query at run time and passes it as a parameter to the finder. Because of this, do not configure query options on these finders. Instead, configure options on the query passed into the finder. For more information about predefined finders, see Section 108.15.1, "Predefined Finders".

7. If required, create an implementation for the query. Some query options require a query definition in code on a helper class, but most common queries do not.

When you use TopLink CMP, define finder methods on the bean's Home interface, not in the entity bean itself. TopLink CMP provides this functionality and offers several strategies to create and customize finders. The EJB container and TopLink automatically generate the implementation.

<entity>...    <query>        <query-method>            <method-name>findLargeAccounts</method-name>                <method-params>                <method-param>double</method-param>            </method-params>        </query-method>    <ejb-ql><![CDATA[SELECT OBJECT(account) FROM AccountBean account WHERE       account.balance > ?1]]></ejb-ql>    </query>...</entity>

111.10.2 How to Use DatabaseQuery Finders

TopLink provides a predefined finder that takes a DatabaseQuery such as a ReadAllQuery. To use this feature in a bean, add the following finder definition to the Home interface of your bean:

public Collection findManyByQuery(ReadAllQuery query) throws RemoteException, FinderException;

public <EJBLocal/Remote> findOneByQuery(ReadObjectQuery query) throws RemoteException, FinderException;

To execute a ReadAllQuery finder, create the query on the client, as Example 111-11 shows.

... {
    ReadAllQuery query = new ReadAllQuery(Employee.class);
    query.addJoinedAttribute("address");
    Enumeration employees = getEmployeeHome().findManyByQuery(query);
}

111.10.3 How to Use Named Query Finders

You can implement an EJB finder method (including TopLink predefined finders) as a named query. For more information, see Section 109.3, "Using Named Queries". You execute such a finder as you would any other.

111.10.4 How to Use Primary Key Finders

TopLink provides a predefined finder (findByPrimaryKey) that takes a primary key as an Object.

... {
    Employee employee = getEmployeeHome().findByPrimaryKey(primraryKey);
}

111.10.5 How to Use EJB QL Finders

EJB QL is the standard query language first defined in the EJB 2.0 specification. TopLink supports EJB QL. EJB QL finders let you specify an EJB QL string as the implementation of the query.

EJB QL offers the following advantages:

• It is the EJB 2.0 and 2.1 standard for queries.

• You can use it to construct most queries.

• You can implement dependent object queries with EJB QL.

The disadvantage of EJB QL is that it is difficult to use when you construct complex queries.

To create an EJB QL finder, use this procedure:

1. Declare the finder on either the LocalHome or the RemoteHome interface.

2. Start TopLink Workbench.

3. Reimport the ejb-jar.xml file to synchronize the project to the file.

   TopLink Workbench synchronizes changes between the project and the ejb-jar.xml file.

The following is an example of a simple EJB QL query that requires one parameter. In this example, the question mark ( ? ) in?1 specifies a parameter:

SELECT OBJECT(employee) FROM Employee employee WHERE (employee.name =?1)

To create an EJB QL finder for an entity bean with container-managed persistence, use this procedure:

1. Declare the finder in the ejb-jar.xml file, and enter the EJB QL string in the ejb-ql tag.

2. Declare the finder on the Home interface, the LocalHome interface, or both, as required.

3. Start TopLink Workbench.

4. Specify the ejb-jar.xml file location and choose File > Updated Project from the ejb-jar.xml file to read in the finders.

5. Go to the Queries > Finders > Named Queries tab for the bean.

6. Add a finder, and give it the same name as the finder you declared on your bean's home. Then add any required parameters.

7. Select and configure the finder.

The following is an example of a simple EJB QL query that requires one parameter. In this example, the question mark ("?") in?1 specifies a parameter.

SELECT OBJECT(employee) FROM Employee employee WHERE (employee.name =?1)

111.10.6 How to Use SQL Finders

You can use custom SQL code to specify finder logic. SQL lets you implement logic that might not be possible to express with TopLink expressions or EJB QL.

To create a SQL finder, use this procedure:

1. Declare the finder in the ejb-jar.xml file, and leave the ejb-ql tag empty.

2. Start TopLink Workbench.

3. Specify the ejb-jar.xml file location and choose File > Updated Project from the ejb-jar.xml file to read in the finders.

4. Go the Queries > Named Queries tab for the bean.

5. Select the finder, select the SQL radio button, and enter the SQL string.

6. Configure the finder.

The following is an example of a simple SQL finder that requires one parameter. In this example, the number sign character ( # ) is used to bind the argument projectName within the SQL string:

SELECT * FROM EJB_PROJECT WHERE (PROJ_NAME = #projectName)

111.10.7 How to Use Redirect Finders

Redirect finders let you specify a finder in which the implementation is defined as a static method on an arbitrary helper class. When you invoke the finder, it redirects the call to the specified static method.

For more information about redirect queries, see Section 108.10, "Redirect Queries".

The finder can have any arbitrary parameters. If the finder includes parameters, TopLink packages them into a Vector and passes them to the redirect method.

Redirect finders offer several advantages. Because you define the redirect finder implementation independently from the bean that invokes it, you can build the redirect finder to accept any type and number of parameters. This lets you create a generic redirect finder that accepts several different parameters and return types, depending on input parameters.

A common strategy for using redirect finders is to create a generic finder that does the following:

• Includes logic to perform several tasks

• Reads the first passed parameter to identify the type of finder requested and select the appropriate logic

The redirect method contains the logic required to extract the relevant data from the parameters and uses it to construct a TopLink query.

The main disadvantage of redirect finders is that they are complex and can be difficult to configure. They also require an extra helper method to define the query. However, because they support complex logic, they are often the best choice when you need to implement logic unrelated to the bean on which the redirect method is called.

To create a redirect finder, use the following procedure:

1. Declare the finder in the ejb-jar.xml file, and leave the ejb-ql tag empty.

2. Declare the finder on the Home interface, the localHome interface, or both, as required.

3. Create an amendment method.

   For more information, see Section 119.35, "Configuring Amendment Methods".

4. Start TopLink Workbench.

5. Choose Advanced Properties > After Load from the menu for the bean.

6. Specify the class and name of the static method to enable the amendment method for the descriptor.

The amendment method then adds a query to the descriptor's query manager, as follows:

ReadAllQuery query = new ReadAllQuery();
query.setRedirector(new MethodBaseQueryRedirector (examples.ejb.cmp20.advanced.
  FinderDefinitionHelper.class,"findAllEmployeesByStreetName"));
descriptor.getQueryManager().addQuery ("findAllEmployeesByStreetName", query);

The redirect method must return either a single entity bean (object) or a Vector. Here are the possible method signatures:

public static Object redirectedQuery(oracle.toplink.sessions.Sessions, Vector args)

and

public static Vector redirectedQuery(oracle.toplink.sessions.Sessions, Vector args)

When you implement the query method, ensure that the method returns the correct type. For methods that return more than one bean, set the return type to java.util.Vector. TopLink converts this result to java.util.Enumeration (or Collection) if required.

At run time, the client invokes the finder from the entity bean home and packages the arguments into the args vector in order of appearance from the finder method signature. The client passes the vector to the redirect finder, which uses them to execute a TopLink expression.

public class RedirectorTest {

    private Session session;
    private Project project;

    public static void main(String args[]) {
        RedirectorTest test = new RedirectorTest();
        test.login();

        try {
            // Create the arguments to be used in the query
            Vector arguments = new Vector(1);
            arguments.add("Smith");

            // Run the query
            Object o = test.getSession()
                .executeQuery(test.redirectorExample(), arguments);
            o.toString();
        }
        catch (Exception e) {
            System.out.println("Exception caught -> " + e);
            e.printStackTrace();
        }
    }

    public ReadAllQuery redirectorExample() {
        // Create a redirector
        MethodBasedQueryRedirector redirector = new MethodBasedQueryRedirector();

        // Set the class containing the public static method
        redirector.setMethodClass(RedirectorTest.class);

        // Set the name of the method to be run
        redirector.setMethodName("findEmployeeByLastName");

        // Create a query and add the redirector previously created 
        ReadAllQuery readAllQuery = new ReadAllQuery(Employee.class);
        readAllQuery.setRedirector(redirector);
        readAllQuery.addArgument("lastName");

        return readAllQuery;
    }

    // Call the static method
    public static Object findEmployeeByLastName(
                           oracle.toplink.sessions.Session session,
                           Vector arguments) {

        // Create a query and set Employee as its ref. class
        ReadAllQuery raq = new ReadAllQuery(Employee.class);
        raq.addArgument("lastName");

        // Create the selection criteria
        ExpressionBuilder employee = query.getExpressionBuilder();
        Expression whereClause =
        employee.get("lastName").equal(arguments.firstElement());

        // Set the selection criteria
        raq.setSelectionCriteria(whereClause);

        return (Vector)session.executeQuery(raq, arguments);
    }
...
}

111.10.8 How to Use the ejbSelect Method

The ejbSelect method is a query method intended for internal use within an entity bean instance. Specified on the abstract bean itself, the ejbSelect method is not directly exposed to the client in the home or component interface. Defined as abstract, each bean can include zero or more such methods.

Select methods have the following characteristics:

• The method name must have ejbSelect as its prefix.

• It must be declared as public.

• It must be declared as abstract.

• The throws clause must specify the javax.ejb.FinderException, although it may also specify application-specific exceptions as well.

• The result-type-mapping tag in the ejb-jar.xml file determines the return type for ejbSelect methods. Set the flag to Remote to return EJBObjects; set it to Local to return EJBLocalObjects.

The format for an ejbSelect method definition should be similar to the following:

public abstract type ejbSelect<METHOD>(...);

The ejbSelect query return type is not restricted to the entity bean type on which the ejbSelect is invoked. Instead, it can return any type corresponding to a container-managed relationship or container-managed field.

Although the ejbSelect method is not based on the identity of the entity bean instance on which it is invoked, it can use the primary key of an entity bean as an argument. This creates a query that is logically scoped to a particular entity bean instance.

To create an ejbSelect method, use this procedure:

1. Update the ejb-jar.xml file as follows:

   • Declare the ejbSelect method.

   • Enter the EJB QL string in the ejb-ql tag.

   • Specify the return type in the resultEtype-mapping tag (if required).

2. Declare the ejbSelect on the abstract bean class.

3. Start TopLink Workbench.

4. Click the project icon in the Navigator, and select: Selected > Update Project from ejb-jar.xml to read in the finders.

5. Go the Queries > Named Queries tab for the bean.

6. Select and configure the ejbSelect method.

111.11.1 How to Handle Cursors and Java Iterators

The TopLink scrollable cursor lets you scroll through a result set from the database without reading the whole result set in a single database read operation. The ScrollableCursor class implements the Java ListIterator interface to allow for direct and relative access within the stream. Scrollable cursors also let you scroll forward and backward through the stream.

ReadAllQuery query = new ReadAllQuery(Employee.class);
query.useScrollableCursor();
ScrollableCursor cursor = (ScrollableCursor) session.executeQuery(query);

while (cursor.hasNext()) {
    System.out.println(cursor.next().toString());
}
cursor.close();

111.11.2 How to Handle Java Streams

Java streams let you retrieve query results as individual records or groups of records, which can result in a performance increase. You can use streams to build efficient TopLink queries, especially when the queries are likely to generate large result sets.

CursoredStream stream;
ReadAllQuery query = new ReadAllQuery(Employee.class);
query.useCursoredStream();
stream = (CursoredStream) session.executeQuery(query);

ReadAllQuery query = new ReadAllQuery(Employee.class);
Enumeration employeeEnumeration;

List employees = (List) session.executeQuery(query);
employeeEnumeration = employee.elements();

while (employeeEnumeration.hasMoreElements()) {
    Employee employee = (Employee) employeeEnumeration.nextElement();
    employee.doSomeWork();
}

ReadAllQuery query = new ReadAllQuery(Employee.class);
query.useCursoredStream();

CursoredStream stream = (CursoredStream) session.executeQuery(query);
while (! stream.atEnd()) {
    Employee employee = (Employee) stream.read();
    employee.doSomeWork();
    stream.releasePrevious();
}
stream.close();

111.11.3 How to Optimize Streams

To optimize CursoredStream performance, provide a threshold and page size to the useCursoredStream(Threshold, PageSize) method, as follows:

• The threshold specifies the number of objects to read into the stream initially. The default threshold is 10.

• The page size specifies the number of objects to read into the stream after the initial group of objects. This occurs after the threshold number of objects is read. Although larger page sizes result in faster overall performance, they introduce delays into the application when TopLink loads each page. The default page size is 5.

When you execute a batch-type operation, use the dontMaintainCache method with a cursored stream. A batch operation performs simple operations on large numbers of objects and then discards the objects. Cursored streams create the required objects only as needed, and the dontMaintainCache ensures that these transient objects are not cached.

111.11.4 How to Use Cursors and Streams with EJB 2.n CMP Finders

Large result sets can be resource-intensive to collect and process. To give the client more control over the returned results, configure TopLink finders to use cursors. This combines TopLink's CursoredStream with the ability of the database to cursor data, and breaks up the result set into smaller, more manageable pieces.

ReadAllQuery raq = new ReadAllQuery(ProjectBean.class);
ExpressionBuilder bldr = raq.getExpressionBuilder();
raq.useCursoredStream();
raq.addArgument("projectName");
raq.setSelectionCriteria(bldr.get("name").
like(bldr.getParameter("projectName")));
descriptor.getQueryManager().addQuery ("findByNameCursored", query);

// import both CursoredCollection and CursoredIterator
import oracle.toplink.ejb.cmp.wls.*;
//... other imports as necessary
getTransaction().begin();
CursoredIterator cursoredIterator = (CursoredIterator) getProjectHome().findByNameCursored("proj%").iterator();
Vector projects = new Vector();
for (int index = 0; index < 50; i++) {
Project project = (Project)cursoredIterator.next();
projects.addElement(project);
}
// Rest all at once ...
Vector projects2 = cursoredIterator.next(50);
cursoredIterator.close();
getTransaction().commit();

111.13.1 How to Cache Results in a ReadQuery

By default, each time you execute a ReadQuery, TopLink applies the current query configuration to the read operation. In doing so, TopLink will access the session cache, the data source, or both.

Some queries are known to return the same result set (for example, the number of units sold last year by the current sales person). After the first query execution, there is no need to actually execute the query if it is invoked again.

For these types of queries, you can use any TopLink ReadQuery and configure it to store its query results in an internal query cache.

After its first execution for a set of query parameters, the query will return its cached result set each time it is invoked with the same query parameters. This improves query performance for frequently executed queries. By default a query will cache the results sets for the last 100 queries of specific parameters. You can configure this query cache as part of the QueryResultsCachePolicy.

Enable this feature using ReadQuery method cacheQueryResults or by calling the ReadQuery method setQueryResultsCachePolicy with an instance of QueryResultsCachePolicy, and disable it using ReadQuery method doNotCacheQueryResults.

Before using this feature, consider the restrictions in Section 108.16.7.1, "Internal Query Cache Restrictions". For more information, see Section 108.16.7, "How to Cache Query Results in the Query Cache".

You can apply a cache invalidation policy to the query's internal cache (see Section 111.13.2, "How to Configure Cache Expiration at the Query Level"). For more information, see Section 102.2.5, "Cache Invalidation".

Example 111-20 shows how to configure a ReadQuery to cache its results.

ReadObjectQuery query = new ReadObjectQuery(Employee.class);

// Instruct the ReadQuery to cache its query results
query.cacheQueryResults();

// The first time you invoke it, the ReadQuery reads from the database, session 
// cache, or both and stores the result set in its internal query cache
Employee employeeFirst = (Employee) session.executeQuery(query);

Example 111-21 shows how to configure the ReadQuery to stop caching its results. The next time the query is executed, TopLink does not use the query cache. Instead, the query accesses the data source.

// Disable query caching
query.doNotCacheQueryResults();

// The ReadQuery does not use the query cahce and instead accesses the database
Employee employee = (Employee) session.executeQuery(query);

Alternatively, you can clear the query's internal cache using ReadQuery method clearQueryResults passing in your session. This clears the currently cached results and ensures that the next query execution reads from the database.

111.13.2 How to Configure Cache Expiration at the Query Level

You can configure a ReadQuery with a CacheInvalidationPolicy.

If you configure a query to cache results in its own internal cache (see Section 111.13.1, "How to Cache Results in a ReadQuery"), the cache invalidation policy allows the cached query result set to expire, based on a time-to-live or daily-expiry. This invalidation time is calculated from the time of the query execution that cached the query result set for the specific set of query parameters.

Example 111-22 shows how to configure a ReadQuery so that a TimeToLiveCacheInvalidationPolicy is applied to all the objects returned by the query and cached in the query's internal cache.

// The TimeToLiveCacheInvalidationPolicy applies to all objects returned by the query and
// cached in the query's internal cache 
readQuery.setQueryResultsCachePolicy(
    new QueryResultsCachePolicy(new TimeToLiveCacheInvalidationPolicy(1000))
);

For more information, see Section 102.2.5, "Cache Invalidation".