Toplink, the DatabaseQuery class and oracle execution paths., Avoiding hardparses

Question

Abstract:

An application I work on uses top link, I'm having trouble finding out if and when top link automatically uses bind variables.

Problem Description:

Lets say I need to do something akin to validating if a vehicle full of people can travel somewhere, where each person could invalidate the trip, and provide error messages so the person could get their restrictions removed before the trip starts. A simple way to do that is to validate each member in the list, and display a list of errors. Lets say their info is stored on an oracle database and I query for each riders info using their unique ids, This query will be executed for each member in the list. A naïve implementation would cause a hard parse, a new execution path, despite only the unique id changing.

I've been reading about bind variables in sql, and how they allow for reuse of an execution path, avoiding cpu intensive hard parses. A couple links on them are:

• http://www.akadia.com/services/ora_bind_variables.html
• https://oracle-base.com/articles/misc/literals-substitution-variables-and-bind-variables

An application I work on uses toplink and does something similar to the situation described above. I'm looking to make the validation faster, without changing the implementation much.

If I do something like the following:

Pseudo-code

  public class userValidator{
  private static DataReadQuery GET_USER_INFO;
  static{
    GET_USER_INFO = "select * from schema.userInfo ui where ui.id= #accountId"
    GET_USER_INFO.bindAllParameters();
    GET_USER_INFO.cacheStatement();
    GET_USER_INFO.addArgument("accountId", String.class);
  }

  void validate(){    
     List<String> listOfUserAccountIds = getuserAccountIdList();
     list args;
     for(String userAccountId: listOfUserAccountIds){
        args = new ArrayList(1);
        args.add(userAccountId)
        doSomethingWithInfo(getUnitOfWork().executequery(GET_USER_INFO, args);
     }
  }
}

The Question:

Will a new execution path be parsed for each execution of GET_USER_INFO?

What I have found:

If I understand the bindAllParameters function inside of the DatabaseQuery class well enough, it simple is a type validation to stop sql injection attacks.

There is also a shouldPrepare function inside the same class, however that seems to have to do more with allowing dynamic sql usage where the number of arguments is variable. A prepared DatabaseQuery has its sql written once with just the values of the variables changing based on the argument list passed in, which sounds like simple substitution and not bind variables.

So I'm at a lost.

Answer 1

This seems answered by the TopLink documentation

By default, TopLink enables parameterized SQL but not prepared statement caching.

So prepared statements are used by default, just not cached. This means subsequent queries will have the added cost of re-preparing statements if not optimized by the driver. See this for more information on optimizations within TopLink