Class: com.sybase.djc.ant.QueryMethodProperty (Query Method Property) | EAServer 6.3 Help |
---|
Description | This property is used to configure object-relational mapping for a query method that is generated during deployment of EJB entity beans. |
---|---|
Configuration |
Configuration is achieved using an XML (Ant) configuration script, such as the following: <project name="ejbjar-example-user"> <import file="ant-config-tasks.xml"/> <target name="configure-user"> <setProperties component="ejb.components.example.Product"> <queryMethod method="findByName(java.lang.String name)" isolationLevel="RepeatableReadWithCache" tableVersion="ref_tv.tv" /> </setProperties> </target> </project>This example assumes the prior deployment of an EJB-JAR file named example.jar. The above script would be placed in file ejbjar-example-user.xml in the config directory of your EAServer installation. To run the script, assuming that the bin directory of your EAServer installation is in the PATH, you would use one of the the following commands: recompile ejbjar-example-user (Windows) recompile.sh ejbjar-example-user (Unix / Linux) Alternatively, the above script can be named sybase-ejbjar-config.xml and placed alongside ejb-jar.xml in the META-INF directory inside an EJB-JAR file (prior to deployment). Note: you can define multiple properties, for multiple components, in the same configuration script. |
Nested Properties | cacheSize, cacheTimeout, distributedCache, ejbql, forPartition, isolationLevel, maxRows, method, parentVersion, preloadBatchSize, preloadCache, preloadThreadCount, preloadUsing, preloadWhere, remote, sql, tableVersion |
Property: distributedCache (Distributed Cache) | |
---|---|
Description | Name of a distributed cache to be used if the isolationLevel property is cache-enabled. Distributed caches generally will not perform as well as local-only caches, but offer the advantages of being able to hold more objects and being able to survive the failure of cluster members. Cache read operations for query methods will be resolved from local cache if possible, and only delegated to the distributed cache if no matching result is found. |
Property: ejbql (EJB-QL Query) | |
---|---|
Description |
The EJB Query Language string for this query.
Note: the query can alternatively be defined using SQL. |
Property: forPartition (For Partition) | |
---|---|
Description | If set to a partition name other than "default", preloading for this query will only be carried out if the current server belongs to the named partition. |
Only Used If | Property preloadCache has the value "true". |
Default Value | default |
Property: isolationLevel (Isolation Level) | |
---|---|
Description |
Specifies a logical isolation level for this query. A
logical isolation level is distinct from the
sqlIsolationLevel
that is applied to any JDBC database connections that
are participating in the transaction. Typically the
SQL isolation level is ReadCommitted, and for some entity classes
or query methods a higher isolation level is requested.
See also isolationLevel (Persistent Object Property). |
Property: maxRows (Maximum Rows) | |
---|---|
Description | The maximum number of rows (or objects) that will be returned by this query. |
Default Value | 0 |
Minimum Value | 0 |
Maximum Value | 2147483647 |
Property: parentVersion (Parent Version) | |
---|---|
Description |
Allows cached query results to be associated with a particular
version of a "parent" object, while guaranteeing a high level
of transactional consistency. The syntax of this property is
"ParentEntity[QueryParameter].version",
The parent entity refers to another entity which uses
versionColumn.
The query parameter is assumed to be the primary key for the corresponding parent object.
This is particularly useful in combination with an isolationLevel
of RepeatableReadWithCache or SerializableWithCache .
As an example, a query "findByCustomer(int p1)" declared on an "Order" entity could be associated with a parent "Customer" entity by using the parent version expression "Customer[p1].version". When this property is used, the cacheChildren property on the parent entity must also refer to this query. |
Property: preloadBatchSize (Preload Batch Size) | |
---|---|
Description | The number of queries to be run per transaction during preloading. The default is to run one query per transaction to avoid acquiring too many database locks. |
Only Used If | Property preloadUsing is not empty. |
Default Value | 1 |
Minimum Value | 0 |
Maximum Value | 2147483647 |
Property: preloadCache (Preload Cache) | |
---|---|
Description |
If the isolationLevel
for the associated persistent object
indicates the use of a cache, then this property
(if true) requests preloading of results into the cache.
Notes:
|
Default Value | false |
Legal Values | false, true |
Property: preloadThreadCount (Preload Thread Count) | |
---|---|
Description | The number of threads to be used for preloading. Note however that if cacheTimeout is non-zero, preloading will be repeated before the timeout expires, and if too many threads are configured for preloading, the repeated preloading may adversely impact other activities in the server. |
Only Used If | Property preloadUsing is not empty. |
Default Value | 1 |
Minimum Value | 0 |
Maximum Value | 2147483647 |
Property: preloadUsing (Preload Using) | |
---|---|
Description |
This should only be used for queries other than "findByPrimaryKey".
When using a query cache for a query other than "findByPrimaryKey",
each cache entry is a query result (or result set) keyed by
query parameters. The query must be run once for each distinct set
of parameters that we wish the results to be preloaded for.
If this property is specified, it must be a SQL query that returns a result set, each row of which is a parameter set for the query. If the "preloadUsing" query is expected to return many rows, consider using preloadBatchSize and/or preloadThreadCount to speed up preloading. As an example, consider a query "findByCity(java.lang.String city)" defined on a Bank entity. We might want our cache preloaded with just those results for large cities. We could then define "preloadUsing" as follows: select c_id from city_tab where c_population > 1000000This will result in the findByCity query being run during preloading, with results cached, for each of the large cities. |
Only Used If | Property preloadCache has the value "true". |
Property: preloadWhere (Preload Where) | |
---|---|
Description |
This should only be used for the "findByPrimaryKey" query.
It is a SQL "where" clause that selects for preloading a subset of all the rows in the underlying table. If not specified, all rows in the table will be preloaded. |
Only Used If | Property preloadCache has the value "true". |
Property: sql (SQL Query) | |
---|---|
Description |
The extended SQL string for this query.
Extended SQL is pre-processed by the persistence manager before
being issued to the database server. In particular, if you are using
SQL to define "finder" or "select" methods for EJB entity beans,
and those methods return local or remote objects (as opposed to
simple or aggregate values), you must specify a binding of each
result set column to a persistent field. This binding is achieved
using the extended SQL "into" clause.
Example (SQL for findByPrimaryKey method for an entity with two persistent fields, "id" and "name"). select c_id, c_name into :id, :name from my_tab where c_id = ?1 Note: the query can alternatively be defined using EJB QL. |
Property: tableVersion (Table Version) | |
---|---|
Description |
The name of a version table and version column (e.g. "ref_tv.version")
representing a single row which holds a version number that is
incremented by the persistence manager (or database server) whenever any row is
deleted, inserted or updated in any of the database tables
referenced by this query. This is particularly useful in
combination with an isolationLevel
of RepeatableReadWithCache or SerializableWithCache .
See also tableVersion (Persistent Object Property). |