Administration Guide
|
 |
 |
|
 |
 |
This chapter describes how to configure application-level settings for AquaLogic Data Services Platform (DSP). The chapter contains the following sections:
You can view and configure runtime settings for DSP-enabled applications, including access control, cache settings, server resources (including thread usage), and log levels.
Note: For details on accessing the Data Services Platform Console (named ldconsole) see Launching the Data Services Platform Console.
To specify general application settings:
The General settings page appears, as illustrated in Figure 5-1. Note that you must be logged into the console using a user name with administrator privileges.
Figure 5-1 General Application Settings Page
Table 5-1 lists the application settings available under the General tab.
|
Specifies whether the configured security policy settings will be enforced for the application. |
||
|
Enables access to the application by default (unless a more specific policy blocks it). If enabled, all users can access resources by default, even unauthenticated users. Disallowing default anonymous access disables access to the application by default (unless a more specific policy permits it). The anonymous access option works only with the WebLogic Authorization provider. |
||
|
Enables or disables (default) the caching of query results for stored queries. For more information about caching, see Configuring the Query Results Cache. |
||
|
The JNDI data source name for the database where the cache is stored. |
||
|
The name of the database table where cached data is stored. The default table name is <appName>_CACHE. |
||
|
A query plan is a compilation of a query. The optimal number of query plans cached depends on the size of the queries. You will need to monitor the memory usage and performance of your server to determine whether to change this setting. |
||
|
The maximum number of threads in the Data Services Platform server pool used to handle query requests. The default setting is 20. The minimum setting is 1. If the specified value is invalid, the server uses the default value of 20. Note: The maximum threads value that you specify here does not affect the WebLogic Server server thread pool. The value specified here applies only to the thread pool created and used by the Data Services Platform query engine for processing requests on application view, web service, or custom function data sources. For more information on configuring thread counts, see Guidelines for Setting Server Thread Count. |
||
|
The maximum number of threads allowed for a single query. Use this to limit the number of threads spawned by a single query. The actual number of threads used will not exceed the maximum number of threads specified in Maximum Threads, regardless of the Maximum Number of Threads Per Query setting. The default setting is 4. The minimum setting is 1. If the specified value is invalid, the server uses the default value of 4. Note: The maximum threads value that you specify here does not affect the WebLogic Server server thread pool. The value specified here applies only to the thread pool created and used by the Data Services Platform query engine for processing requests on application view and web service data sources. For more information on configuring thread counts, see Guidelines for Setting Server Thread Count. |
||
|
The verbosity of the events logged. The options include the following:
The log file is in the following location: <BeaHome>\user_projects\domains\<domainName>\ |
It is frequently desirable to change the location of data sources or names of other artifacts as you move applications from development to staging to production. For example, if you are using "dummy" data sources during development in order to protect confidential or otherwise secured information, you will at some point need to substitute a new data source with the actual data for the test version. You can make these changes through the Data Services Platform Console.
In modifying end points you are not limited to the name and location of a data source. It is also possible to change the target names of subordinate artifacts. In the case of relational sources this includes catalog name, schema names, package names, table names, and stored procedure names.
Note: Once set, end point modifications are effective until they are further modified or reverted to the original name. To assign the end point name its original value, simply click Reset to original value. This option will not revert the value to the previous setting, it will directly revert it to the original name. So, if you have assigned a few names over time, the moment you click Reset to original value, the values revert to the same as those in the Original Value column.
Figure 5-2 Setting End Points for Relational Sources
Note: Whenever you change the end point for an artifact you need to ensure that the intrinsic aspects of that artifact remain identical with the old source. In the case of a relational source properties such as Vendor Type and Version must be identical.
When you change the end point of a particular object, the new end point appears in brackets next to the original name. Figure 5-3 below displays the original data source name, and the new data source name (in square brackets) adjacent to it.
Figure 5-3 End Point Settings Reflected in the Navigation Pane
Table 5-1 identifies the artifacts whose end point settings can be changed.
You can view a list of data services and function libraries that use the defined relational databases. Click the Where Used tab to view the list of data services and their specific paths (Figure 5-4).
Figure 5-4 Physical Data Services Relational Dependencies
The optimal thread count settings you configure depends on the physical resources of the machine on which you deploy Data Services Platform, the anticipated load, and the type of application you are deploying. Increasing the number of threads can accelerate processing, but since each thread consumes memory, you must achieve a balance based on the available resources.
Use the following general guidelines for settings the thread count:
Data Services Platform only uses the thread pool for acquiring web service calls; threads are only spawned when web services are invoked by queries. Therefore, an application that does not rely on web service content can have a relatively low thread count setting.
For more information on tuning performance for the WebLogic Server and applications, see the following:
http://download.oracle.com/docs/cd/E13222_01/wls/docs81/perform/index.html
You can view statistics and status information for a Data Services Platform application, particularly relating to query activities, using the Monitor tab. You can also monitor active application processes, displaying information such as the user who initiated the process, the time is has been running, and the number of cached entries for the process type.
The General settings page appears. Note that you must be logged into the console using a user name with administrator privileges.
The monitoring information for the application appears, as illustrated in Figure 5-5.
Figure 5-5 DSP Administration Console Application Monitor Tab
Table 5-2 describes the information displayed in the Monitor tab.
Once invoked, a data service function runs until either it gets a result or a time-out expires (assuming a time-out period is set). The time-out setting enables you to specify, in the query, the maximum time a query should wait for unresponsive data sources.
In some cases, it may be necessary to cancel the execution of a function. The Monitor tab enables you to view and cancel currently running queries. The page also displays the user associated with the query and cache information.
When you terminate a process, the operation in progress finishes, then the process completes without executing subsequent nodes.
Note: The submit query is rolled back only in cases when you are using the XA driver.
To terminate function execution:
Note: Terminating a query triggers a weblogic.xml.query.exceptions.XQuerySystemException on the client.
An administrative property is a user-defined property that you can configure using the DSP Console. The value of an administrative property can be used in XQuery functions, either in data service functions or security XQuery functions.
Note: For information on security XQuery functions, see Securing Data Services Platform Resources.
An administrative property is a convenient way of having function parameters that can be easily changed by the administrator, without having to modify the body of either the data service function or security XQuery function.
The administrative property has application scope — any data service in the application can use the property value. The property value can be accessed using XQuery with the BEA function get-property(). The function takes the name of the property as an argument and returns the value as a string. It also takes an argument that serves as the default value for the parameter. This value is used if the property is not configured in the console.
The following shows a complete example of an XQuery Function Library function using an administrative property:
declare function f1:getMaximumAccountViewable() as xsd:decimal {
let $amount := fn-bea:get-property("maxAccountValue", "1000.00")
cast as xsd:decimal
return $amount
};
To manage administrative properties:
Figure 5-6 Administrative Properties Tab
Table 5-3 describes the information displayed in the Administrative Properties tab:
In some instances, Data Services Platform may not be able to read data from a database table because another application has locked the table, causing queries issued by Data Services Platform to be queued until the application releases the lock. To prevent this, you can set the transaction isolation to read uncommitted in the JDBC connection pool on your WebLogic Server.
To set the transaction isolation level:
http://<HostName>:<Port>/console
For example, to start the Administration Console for a local instance of WebLogic Server (running on your own machine), type the following URL in a web browser address field:
http://localhost:7001/console/
The Connections tab appears, as illustrated in Figure 5-7.
|
|
|
) next to the property.