Should I Cache PreparedQuery Objects for TableAccessors
Article ID: KB0075725
Updated On:
| Products | Versions |
|---|---|
| TIBCO Streaming | - |
Description
Should I Cache PreparedQuery Objects for TableAccessors?
Issue/Introduction
Guidance to cache PreparedQuery Objects for TableAccessors
Resolution
Yes, cache PreparedQuery objects for TableAccessors.
In the set of APIs oriented around com.streambase.sb.operator.TableAccessor, it’s required to use use TableAccessor.prepare() to create PreparedQuery objects that you then execute() to perform reads of Query Tables.
Currently, the sample_TableOperator/java-src/com.streambase.sample.QueryJava class’s processTuple() method creates a new PreparedQuery object for tuple. This makes some sense, because in this sample the query predicate comes from the input tuple.
In general, however, creating a new PreparedQuery per input tuple is going to be expensive. That’s because TableAccessor.prepare() creates a new JVM class that represents the query. Not a lightweight operation.
Therefore, consider making a local cache of PreparedQuery objects keyed by unique TableAccessor/predictate/schemaArgs triples and re-using them for similar queries.
This advice is based on the API and runtime implementation in effect from StreamBase 7.2.0, when the API was introduced, through at least StreamBase 10.5, when this note was updated. As of now, the API doesn’t do any PreparedQuery caching on its own. Not that it necessarily should; analogously the JDBC API does not cache PreparedStatements, either, and the developer community takes care, generally, not to over-create PreparedStatements. Similarly, appropriate use of TableAccessor.prepare() is a developer responsibility as well.
In the set of APIs oriented around com.streambase.sb.operator.TableAccessor, it’s required to use use TableAccessor.prepare() to create PreparedQuery objects that you then execute() to perform reads of Query Tables.
Currently, the sample_TableOperator/java-src/com.streambase.sample.QueryJava class’s processTuple() method creates a new PreparedQuery object for tuple. This makes some sense, because in this sample the query predicate comes from the input tuple.
In general, however, creating a new PreparedQuery per input tuple is going to be expensive. That’s because TableAccessor.prepare() creates a new JVM class that represents the query. Not a lightweight operation.
Therefore, consider making a local cache of PreparedQuery objects keyed by unique TableAccessor/predictate/schemaArgs triples and re-using them for similar queries.
This advice is based on the API and runtime implementation in effect from StreamBase 7.2.0, when the API was introduced, through at least StreamBase 10.5, when this note was updated. As of now, the API doesn’t do any PreparedQuery caching on its own. Not that it necessarily should; analogously the JDBC API does not cache PreparedStatements, either, and the developer community takes care, generally, not to over-create PreparedStatements. Similarly, appropriate use of TableAccessor.prepare() is a developer responsibility as well.
Feedback
Yes
No
Powered by
