Skip Headers
Oracle® Database Lite Administration and Deployment Guide
10g (10.3.0)

Part Number B28922-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

A Configuration Parameters for the WEBTOGO.ORA File

This document describes configuration parameters for the in the webtogo.ora file. The Mobile Server uses the webtogo.ora file to initialize the Mobile Server; thus, if you modify these parameters, you must restart the Mobile Server to receive the change.

The following sections define system-wide parameters for the Mobile Server:

A.1 [APPLICATIONS]

Table A-1 lists the APPLICATIONS parameters and their usage definitions.

Table A-1 APPLICATIONS Parameters

Parameter Definition

PACK_HELP

Location for the Packaging Wizard help file. This is only used with MDK. and only for the purpose of Debug / Support.

XMLFILE

Name of the XML file used by the Packaging Wizard to store the application information. This is only used for Debug / Support.


A.2 [WEBTOGO]

The following WEBTOGO parameters control the behavior of both the Mobile client for OC4J or Web-to-Go and the Mobile Server.

Table A-2 lists WEBTOGO parameters and their usage definitions.

Table A-2 WEBTOGO Parameters

Parameter Definition

ADMIN_PASSWORD

Encrypted user password. Users must not try to edit the encrypted password. This parameter can be set by navigating to the following URL.

<server>/webtogo/startup

ADMIN_PORT=8080

Admin port for starting the Mobile Server.

ADMIN_JDBC_URL=jdbc:oracle:oci8@webtogo.world

Mobile Server Repository JDBC URL.

ADMIN_USER

Encrypted user name. Users must not try to edit the encrypted user name. This parameter can be set by navigating to the following URL.

<server>/webtogo/startup

APPLET_USE_THIN_JDBC=YES

Requests that JDBC use the thin driver or the Web-to-Go data communication link for all database calls. Web-to-Go uses the internal Web-to-Go JDBC driver, if it is not using the JDBC thin driver. If this parameter is set to YES, then the parameter THIN_JDBC_URL should also be set.

APPLET_SUPPORT_ENABLE=YES

If you want to run an applet that uses a JDBC connection on the Mobile client for OC4J or Web-to-Go, you must set this parameter to YES and restart the client.

If the applet does not use a JDBC connection, you need not set this parameter. Setting this parameter to YES for an applet that does not use a JDBC connection, does not impair your settings.

BIND_IP

Applicable for Web-to-Go Client only. Specify the IP address on which the Web-to-Go listener is bound. By default, the listener is started on the local host.

Use this parameter if you have a machine where there is more than one IP address. Define the IP address you wish to use as the Web-to-Go listener and then start the Web-to-Go client listener on that IP address.

CUSTOM_WORKSPACE=no

Indicates whether or not a custom workspace should be used.

CUSTOM_DIRECTORY=/myworkspace

Location of the custom workspace files in the repository.

CUSTOM_FIRSTSERVLET=HelloWorld;/hello

Use this parameter to add the first servlet to the custom workspace. Within the first servlet, you can add more servlets to the custom workspace, using the addServlet() call.

Format: class;virtual path

DEFAULT_PAGE=myfirstpage.html

The first page of the custom workspace. This page appears when the user accesses the following URL.

http://<server>/webtogo

DEFAULT_CLIENT_1CLICK

The default value for the Mobile Client's "use default setting for sync"

Sample Value: YES

DEFAULT_CLIENT_UPGRADE

The default value for the Mobile Client's "ask before upgrade" setting.

Sample Value: YES

DEFAULT_CLIENT_SYNCONLY

The default value for the Mobile Client "offline only/online/offline" setting.

Sample Value: YES

DISABLE_REMOTE_ACCESS

If set to YES, blocks a remote machine getting access to the Mobile Client for Web or Mobile Client for BC4J. You can set this parameter in the client side webtogo.ora file. Once this parameter is set and Mobile Client is restarted, only the request coming from the local machine is served by the Mobile Client listener. Any other request is blocked and not served.

Default value is NO, which is necessary for Branch Office.

DM_AUTO_SYNC_CACHE

Set to YES to turn on this feature to force the DeviceManager to synchronize the cached data on user-related events, such as create, edit or delete user.

ENABLE_USER_ONLINE_ACCESS

Set to TRUE to enable all valid users to log on to the Mobile Server in the Direct Access mode. By default, only users with Administrator privilege level can log in to the Mobile Server in the Direct Mode. Direct mode is when you point the browser directly to the Mobile Server.

FONT_NAME=Arial

The Web-to-Go Workspace font.

IAS_MODE

This parameter must be set to the value YES only if the Mobile Server is running as a component of Oracle9iAS.

Example: IAS_MODE=YES

If the Mobile Server is running in Standalone mode or as a component of Oracle9iAS 1.0.2.2.0, this parameter must be set to the value NO.

The default value is NO.

INSTALLATION_TYPE

Mobile Server Installation Type, such as STANDALONE, IAS10.1.2.0.0, IAS10.1.3.1.1.0, and so on. Do NOT modify, for internal use only.

IP_CONFIG

Set this parameter in the webtogo.ora file on the Mobile Server to designate what type of IP address the client uses. This parameter specifies if your client device is using static IP address or a dynamic (DHCP) method of retrieving an IP address. If you are using DHCP, then you need to set this parameter to DYNAMIC; the default is STATIC.

If you are using DHCP, then the underlying code needs to know to not use the IP address that was used for the previous connection/synchronization. If you are using DHCP and have set this parameter to STATIC, your synchronization may never occur, since it is probably trying to synchronize to an IP address that is no longer valid for this device.

Internally, the IP_CONFIG defines if IP address caching occurs in the JVM. Thus, if the IP_CONFIG parameter is set to DYNAMIC, the JVM security property networkaddress.cache.ttl is set to "0", which determines that the JVM always requests a naming service lookup to retrieve the IP address for the client.

Disabling Java IP caching may effect performance with the additional DNS lookups. In addition, there is a risk of DNS spoofing. See the Sun Microsystems Java documentation for more information.

LOADBALANCE_URL

If the loadbalancer is used for balancing two or more Mobile Servers, then you may include the LoadBalancer URL with port number. Format is <hostname>:<port>.

MAX_THREAD_POOL

Limits the number of threads available in the connection pool. If threading problems occur, set this parameter to 0 or 1.

MODE=SERVER

The mode the Mobile Server is running in. Valid modes are SERVER, CLIENT, and BRANCH. The value BRANCH indicates that the Mobile Server is running in BRANCH mode for client operations.

OC4J_CONFIG_DIR

Location of the OC4J configuration files that are used by the Mobile Server during runtime.

ORACLE_HOME

Location of the Oracle Home where the Mobile Server is installed.

PORT=80

The port number on which the Mobile Server is running. Not valid in Oracle9i Application Server (Oracle9iAS) installation.

PROXY_SERVER=proxy.com

The proxy host name and number. The Mobile client for OC4J or Web-to-Go setup modifies this entry.

PROXY_PORT=80

The proxy port number. The Mobile client for OC4J or Web-to-Go setup modifies this entry.

PUBLIC_NAME=/public

The public URLs name. The default value is /public.

REGISTRY_TAB

Turn this parameter on (TRUE) if your application is using the registry setting and you want to manage the registry settings in the Mobile Manager. This parameter enables the registry tab in the Mobile Manager and is only for backward capability.

RESTRICTED_ADMIN_HOSTS=<list of comma separated IP addresses>

This parameter provides security for accounts with Administrator access. With this parameter, the Mobile Server can be configured to allow login requests to a specified set of IP addresses for accounts with Administrator access.

With this parameter, you can also restrict access to the Mobile Server Startup feature. Only valid login requests from a browser that runs on machines whose IP address is listed as a value of this parameter will be granted access.

For example, RESTRICTED_ADMIN_HOSTS=144.125.127.150,144.125.127.101

Note: Users who have Administrator access should not connect through a proxy server.

REVERSE_PROXY

Set this parameter if a Reverse proxy is used with the Mobile Server. See Section 11.5.1, "Using Reverse Proxy to Communicate from Internet to Intranet" for details.

SERVER_URL=http://<mobile_server_name>:<port_number>/webtogo

This parameter points to the Mobile Server. It communicates with the Mobile Server over HTTP or HTTPS. Usually, you need not modify this parameter. If you want to run the Mobile client for OC4J or Web-to-Go and download the Mobile client for OC4J or Web-to-Go from the following URL, https://<mobile_server_name>/setup, the Mobile client for OC4J or Web-to-Go is automatically configured for SSL, and no manual configuration is required. The Mobile Client communicates with the Mobile Server over SSL.

However, if you do not download the Mobile client for OC4J or Web-to-Go from the Mobile Server that is running in SSL mode and you want to run your Mobile Server in SSL mode, you must modify the SERVER_URL parameter in the configuration file webtogo.ora, on the client side as displayed in the left column.

SSO_ENABLED

Turn this parameter on (TRUE) if you want to enable Oracle Single Sign on (SSO) authentication on the Mobile Server. If this parameter is turned on then the users trying to connect to the Mobile Server in the online mode will receive the login page from the SSO server.

SYNC_CANCEL

This parameter can be set on the client side to determine if the "Cancel" link should appear on the synchronization page.

If this parameter is set to YES, the "Cancel" link appears on the synchronization page. By clicking the Cancel link, you can stop the data synchronization. The link will not appear after the data synchronization is complete.

SQL_RETRIES=5

Number of attempts to modify a JDBC connection before timing out.

SSL=YES

If this parameter is set to YES, then the Mobile Server runs in SSL mode. To use this feature, the Mobile Server should be running as a module inside Oracle9i Application Server (Oracle9iAS).

THIN_JDBC_URL:jdbcoracle:thin:@foo-pc:1521:orcl

The Mobile Server Repository's thin JDBC URL. This URL is used by the JDBC thin driver to connect to the Mobile Server Repository database.

USE_SYSTEM_CLASSPATH=YES

If set to yes, searches for Java classes in the computer's classpath before searching the Mobile Server Repository.

WTG_PROXY

HTTP proxy used to connect to the Mobile Server for application deployment.

Sample Value: www-proxy.dlsun1.com

WTG_PROXY_PORT

HTTP proxy port used to connect to the Mobile Server for application deployment.

Sample Value: 80


A.3 [FILESYSTEM]

The following FILESYSTEM parameters control the behavior of the Mobile Server Repository.

Table A-3 lists [FILESYSTEM] parameters and their definitions.

Table A-3 FILESYSTEM Parameters

Parameter Definition

TYPE

Type of File system.

OL - Oracle Lite based file system.

OS - Operating system's file system.

MIXED - Mixed file system.

PRIMARY=OL

Primary file system in MIXED mode.

SECONDARY=OS

Secondary file system in MIXED mode.

ROOT_DIR=ORACLE_HOME/MOBILE/SERVER/REPOSITORY

Root Directory. Valid only for OS file system.

This directory path format applies to the environment where the Mobile Server runs on Solaris.

Replace ORACLE_HOME with your actual Oracle Home.

ROOT_DIR=ORACLE_HOME\MOBILE\SERVER\REPOSITORY

Root directory. Valid only for OS file system.

This directory path format applies to the environment where the Mobile Server runs on Windows NT.

Replace ORACLE_HOME with your actual home.


A.4 [DEBUG]

The following DEBUG parameters control the debugging messages in the Mobile Server.

Table A-4 lists DEBUG parameters and their definitions.

Table A-4 DEBUG Parameters

Parameter Name Definition

TRACE_ENABLE

Used to turn the trace feature on or off. When the Trace feature is off, trace output is not generated. This value is only overridden when the Mobile Server is running in Standalone mode and with the -d0 command line option on. For example: TRACE_ENABLE=NO Is overridden by -d0 and the trace output is generated to the Console instead of being generated to a file.

Sample Value: YES

TRACE_DESTINATION

Trace destinations are Console and File. The Administrator can set this parameter to any of these destinations. The Console option generates trace output to the console screen.

Note: This trace destination is available only when the Mobile Server is running in Standalone mode. If you set this parameter to the option -d0, the trace output appears on your Console window without appearing in a file, because using the -d0 option with this parameter overrides the trace settings for other trace parameters, such as destination and level, in the webtogo.ora file. The -d0 setting enforces the trace output to appear on your console screen instead of appearing in a file.

The File option generates trace output to a file. For more information, see TRACE_FILE_ NAME, TRACE_FILE_SIZE, and TRACE_FILE_POOL_SIZE.Sample Value: TRACE_DESTINATION=FILE

TRACE_FILE_NAME=trace.log

Used as base name to arrange trace files in sequential order starting from 1 to FILE_TRACE_POOL_SIZE.

For example: If you set the following parameters.

TRACE_FILE_NAME=mytrace.log

TRACE_FILE_POOL_COUNT=5

then, the Trace files will be named mytrace1.log, mytrace2.log, mytrace3.log, mytrace4.log, mytrace5.log, based on how you set the TRACE_FILE_PER_USER parameter.

Sample Value: trace.log

TRACE_LEVEL=1

There are three levels of trace messages:

1(binary 00000001), Basic Trace: General system information, most of the Web-To-Go trace output belongs to this level.

2 (binary 00000010), Function Trace: Traces the function sequence being called, mostly used by Data Synchronization.

4 (binary 00000100), SQL Trace: Traces SQL queries being executed, mostly used by Data Synchronization.

In addition, all errors and exceptions are sent to level -1, which have the binary 11111111. All Java System.out output are sent to level 9. Both these two levels are always generated as output, if the user is not filtered out. For more information, see TRACE_USER.The parameter value for TRACE_LEVEL is used to do a Bitwise AND operation against all 3 trace levels. If the result is greater than 0, then trace output of that level will be generated as trace output.

The parameter value for TRACE_LEVEL used to do a Bitwise AND operation against all 3 trace levels. If the result is greater than 0, then trace output of that level will be generated as trace output.

EXAMPLE: If you set the following parameters, TRACE_LEVEL=3, then the Basic and SQL level trace output is generated, but not Function level trace as the & character is a Bitwise AND operator.

3 & 1 (Basic) = 1 > 03 & 2 (SQL)  =  2 > 03 & 4 (Function) = 0 = 0

TRACE_USERS

List of valid user names. The user trace and system trace information which is listed is generated as trace output.

If the value is an empty string "", then every user is traced. If the value is or contains TRACE_NO_USER, then no actual user is traced. Only the system trace information is generated as trace output.

Note: As the administrator, you must not use the TRACE_NO_USER value as the user name.

Example: If you set this parameter as follows, TRACE_USERS=jane,jack, then only jane and jack's trace information is generated and displayed as trace output.

TRACE_FILE_PER_USER=YES

Used to specify an individual trace file pool for every individual user. Applicable only when the File option is the Trace destination.

If set to YES, then every traceable user has an own trace file pool, and the trace file name includes the user's name. In addition, the system trace output goes to the user's system trace file.

If set to NO, all traceable users share the same trace file pool, the actual trace file does not contain any user name.

Example: TRACE_FILE_POOL_PER_USER=No

TRACE_FILE_SIZE=10

Used as the maximum file size in MB for trace files. If the threshold value is about to be reached, the trace feature generates output to the next trace file in the pool. For more information, see TRACE_FILE_NAME, TRACE_FILE_POOL_SIZE, and TRACE_FILE_PER_USER.

TRACE_FILE_POOL_SIZE=5

The default value is 5. This parameter specifies the number of files in the trace file pool. If the pool limit is reached, the trace output is overwritten to the first file in the pool. See also TRACE_FILE_NAME, TRACE_FILE_POOL_SIZE, and TRACE_FILE_PER_USER


A.5 [PUBLIC]

The following PUBLIC parameters control public availability of servlets in the Mobile Server. To make a servlet public, you can use the parameters as listed in the following table.

Table A-5 lists PUBLIC parameters and their definitions.

Table A-5 PUBLIC Parameters

Parameter Name Definition

myservlet=/<virtualpath>

To call this public URL from your application, call it as follows:

http://<server>/public/<virtual path>

For example, oracle.codeMyservlet=/my servlet

oracle.codeMyservlet=/myservlet


A.6 [SERVLET_PARAMETERS]

In the SERVLET parameters section, you can list the set of custom parameters which are available to all servlets inside the Mobile Server.

Table A-6 lists SERVLET_PARAMETERS and their definitions.

Table A-6 SERVLET Parameters

Parameter Name Definition

MY_VAR=MY_VALUE

Custom parameter which can be accessed by all servlets.


A.7 [CONSOLIDATOR]

The CONSOLIDATOR parameters control the behavior of Data Synchronization. The values that are listed in the following table are default values.

A.7.1 Data Synchronization Parameters

Table A-7 Consolidator Parameters

Parameter Name Definition

APPLY_TRIES_DELAY

Specifies in seconds the delay between successive attempts to apply a client's In Queue. Related to the MAX_APPLY_TRIES parameter.

CACHED_USERS

Comma-separated list of users, where each user's downloaded data is cached.

CLIENT_RESEND_CHECK

If set to YES, then all client resend sessions requests are rejected. This is the default. If a client uploads a transaction and the server receives and processes it correctly, but the client is not notified, then the client will send the transaction again. To avoid having this transaction be processed again, the resend session request is rejected.

However, if you are developing an application and you are executing a test, such as a performance test, you will resend the same client request to the server repeatedly to test how the server responds under heavy load. Only in this case would you want to set this parameter to NO.

COMPOSE_TIMEOUT=300

Specifies in seconds the MGP timeout for the compose phase for each user to complete. If the compose phase for this user does not complete, MGP retries the compose phase for this user in the next cycle. If the compose consistantly fails then increase timeout value. Monitor the MGP logging to evaluate how long the compose takes to complete; then add 50% to the value ensure that slightly larger datasets compose completely.

CONN_CHECK_ON_RESERVE

Configure whether to validate a database connection before retrieving (borrowing) it from the connection pool. By default, this value is YES.

CONN_CHECK_ON_RELEASE

Configure whether to validate the database connection before releasing it back to the connection pool. By default, this value is YES.

If the examination determines that the connection is not valid, then it is destroyed instead of being returned to the connection pool.

CONNECTION_POOL=YES

Enables pooling of database connections if set to YES.

CONNECTION_TIMEOUT=120

Specifies in minutes the JDBC connection timeout for the synchronization session. If synchronization takes longer than the value specified in this parameter, then the server can automatically disconnect. To avoid the connection from timing out during a valid synchronization, then set this value higher.

DO_APPLY_BFR_COMPOSE

By default, before the MGP processes the Compose phase for a user, it checks to see if user data has been uploaded into the In Queue. If so, then the Compose is not performed to ensure that user data is not overwritten. Instead, the Compose phase is not executed until the MGP runs the Apply/Compose phase again.

Setting DO_APPLY_BFR_COMPOSE to true modifies this behavior. If data for a user is in the in queue, MGP will execute a second Apply to commit all user data and then will execute the Compose for that user.

IN_QUEUE_INDEX_ATTRIBUTES

Specify the index attributes for the In Queue table indexes, which exist in the back-end Oracle database. These can include the storage characteristics and the following attributes: TABLESPACE, PCTFREE, PCTUSED, INITRANS, and MAXTRANS. See the Oracle Database SQL Reference for more information on these properties.

IN_QUEUE_TABLE_PROPERTIES

Specify the physical and/or table properties for the In Queue tables, which exist in the back-end Oracle database. These can include the storage characteristics and the following properties: TABLESPACE, PCTFREE, PCTUSED, INITRANS, and MAXTRANS. See the Oracle Database SQL Reference for more information on these properties.

JDBC_URL

This is the JDBC_URL used by the Sync Service and the MGP for connections to the Mobile Server Repository. If absent, it defaults to the ADMIN_JDBC_URL in the WEBTOGO section of the webtogo.ora file.

JOB_ENGINE_AUTO_START

If set to YES, the Job Scheduler is started up at Mobile Server start time.

JOB_ENGINE_SLEEP_TIME

The amount of time in seconds that the Job Scheduler sleeps in each loop.

LOG_LOCK_DELAY

Specifies in the number seconds the delay between successive attempts to lock the log tables. Related to the MAX_LOG_LOCK_TRIES parameter.

MAGIC_CHECK

Control the magic number checking of publication items. If enabled, and there is a mismatch between the server and the client magic numbers, then the publication item receives a complete refresh. If set to ALL, then the magic check is enabled, which is the default. If NONSHARED, then the magic check is enabled only for publication items that are not shared among users. if set to SHARED, then the magic check is enabled only for shared publication items.

A shared publication item has the following characteristics:

  • Read only

  • The publication item query either has no parameters or all users share the same parameter values.

Setting to NONSHARED is useful when creating a installation CD for users that share data. See Section 9.8, "Creating a Single Package or Shared CD for Users That Share Data" for more information.

MAP_INDEX_ATTRIBUTES

Specify the index attributes for the map table indexes, which exist in the back-end Oracle database. These can include the storage characteristics and the following attributes: TABLESPACE, PCTFREE, PCTUSED, INITRANS, and MAXTRANS. See the Oracle Database SQL Reference for more information on these properties.

MAP_TABLE_PROPERTIES

Specify the physical and/or table properties for the map tables, which exist in the back-end Oracle database. These can include the storage characteristics and the following properties: TABLESPACE, PCTFREE, PCTUSED, INITRANS, and MAXTRANS. See the Oracle Database SQL Reference for more information on these properties.

MAX_APPLY_TRIES

Specifies the maximum number of times the MGP retries to apply the client In Queue data before terminating the apply phase.

MAX_BATCH_SIZE

JDBC performance parameter which defines the number of DML records (inserts only) to send from the Mobile Server to the back-end Oracle database at one time. Without batching, each record is sent to the database one at a time. These records are originally from client.

This only applies to insert, and not to delete or update records.

MAX_CONNECTIONS=1000

Sets the maximum number of JDBC connections that can be open at one time by the Mobile Server. When this number is reached, no further synchronization sessions are allowed until active connections are released back to the connection pool.

MAX_CONCURRENT

Sets the maximum number of concurrent active synchronization sessions. When this number is reached, subsequent synchronization session requests are placed in a FIFO queue, and are only allowed to continue when active sessions complete and slots become available. This parameter is designed to prevent the Mobile Server from being overloaded by concurrency and can help to improve throughput when the hardware is being stressed.

Active sessions are concurrently processed and the sessions where users are waiting to be processed are placed in a FIFO queue. The MAX_CONCURRENT variable is the maximum number of active sessions. If after the MAX_CONCURRENT_TIMEOUT, the number of active sessions is still at the maximum, then the waiting sessions that are older than the MAX_CONCURRENT_TIMEOUT are disconnected. Then, the client receives an error that the synchronization has failed. The Oracle Lite client resends the same request during next synchronization, which consists of a push-only resend for the transaction that failed and another synchronization for any new uploaded data.

MAX_CONCURRENT_TIMEOUT

Sets the maximum number of seconds to wait

MAX_LOG_LOCK_TRIES

Specifies the number of attempts to lock the logs before giving up the compose phase.

MAX_THREADS=3

Specifies the number of threads spawned within the MGP process. This parameter value should be set to an equivalent number of CPUs. We recommend this value is set to 1.5 times the number of CPUs. The default is 3.

MGP_CYCLES_BEFORE_INS_CHK

How often should MGP compose phase look for map table records that are marked for deletion but have been re-added to the subscription. By default, this is set to 1. If the application logic guarantees that such records never exist, then this check may be skipped altogether by setting the value to –1, which improves MGP compose performance.

MGP_HISTORY

If set to YES, enables MGP history recording, which can be viewed in the Data Synchronization section of the Mobile Manager.

MGP_PORT

The IP port used by MGP to report current state and/or coordinate multiple instances of the process. The default port number is 7373.

REPORT_ALL_ERRORS

If set to YES, then the MGP attempts to detect and report all apply transaction errors. If set to NO, which is the default, only the first error is reported.

RESUME_CLIENT_MAXSEND

The RESUME_CLIENT_MAXSEND parameter is the maximum data size, in KB, that the client should send in a single POST request. This is used in cases where there is a proxy with a small limit on the data size in one request. Specifying a reasonable value, such as 256 KB, can also help clients with limited storage space, as they can free the chunks that have already been transmitted and acknowledged. The default is 1024 KB.

Set the maximum data size in KiloBytes sent by a client in a single POST request. Some proxies maintain fixed limits on data size in one request.

RESUME_CLIENT_TIMEOUT

The RESUME_CLIENT_TIMEOUT parameter is the number of seconds that the client should use to timeout network operations. The default is 60 seconds.

Set the total number of seconds that the client should use to resume network timeout operations.

RESUME_FILE

This is a server-side parameter that defines the filename of the resume buffer. By default, we use memory mapped file; however, with this parameter, users can provide their own storage files. The size of this file is specified by the RESUME_FILE_SIZE parameter.

RESUME_FILE_SIZE

Set the maximum size of the resume file in MegaBytes (MB).

RESUME_MAXACTIVE

The RESUME_MAXACTIVE parameter controls the maximum number of connections taht the Mobile Server handles at a single time. If more clients try to connect, they are queued until existing connections complete. The default is 100 connections.

RESUME_MAXCHUNK

The RESUME_MAXCHUNK parameter causes the server to drop the connection after sending the specified data size, in KB. This forces the client to reconnect and inform the server on how much data it already has. The server can the discard all data before that offset. The fault value is 1024 KB.

RESUME_TIMEOUT

The RESUME_TIMEOUT parameter indicates how long to keep client data while the client is not connected. The default is 0, which means that resume is disabled and after disconnection, the client data is discarded. A short timeout, such as 15 minutes, is suitable to resume any accidentally dropped connections. A longer timeout may be needed if users explicitly pause and resume synchronization to switch networks or use a dialup connection for another purpose.

SKIP_INQ_CHK_BFR_COMPOSE

By default, before the MGP processes the Compose for a user, it checks to see if user data has been uploaded into the In Queue. If so, then the Compose for the user is not performed to ensure that user data is not overwritten. Instead, the Compose phase is not executed until the MGP runs the Apply/Compose phase again.

Setting SKIP_INQ_CHK_BFR_COMPOSE to true modifies this behavior. Even if data is in the in queue, MGP executes the Compose for the user. The data that was uploaded to the In Queue must be data that will not be compromised by downloading data from the server to the client.

SLEEP_TIME=20000

Specifies how long (in milliseconds) the MGP sleeps before scheduling the next client's apply phase. By default, it is set to 2 milliseconds.

STMT_CACHE_SIZE

The number of prepared statements to be cached for each connection. These statements are not re-parsed by the database when they are prepared again. To turn off caching, set this variable to -1.

SYNC_HISTORY

If set to YES, enables synchronization history recording, which can be viewed in the Data Synchronization section of the Mobile Manager.

SYNC_SERVICE_AUTO_START

If set to YES, the Sync Server is started automatically at Mobile Server startup. The client cannot synchronize until the Sync Server is started. So, if you want to prevent the client from synchronizing, then set this parameter to NO and then start and stop the Sync Server manually through the Mobile Manager after you have completed the tasks that you want to perform while the client is unable to synchronize. For example, you do not want a client to synchronize if you are re-publishing the client's application.

TEMP = C:\TEMP

Specifies the directory where the binary trace file, which includes the request and response data, is written. This file is created to cache the data in transport, so that if a failure occurs, Oracle Lite can recover. You initialize this binary trace file by selecting the Data Trace Type checkbox.

USE_JVM_COMPRESSION

Specifies whether the JVM implementation of ZIP or the Oracle pure Java version for compression should be used. This is a performance parameter, where depending on a particular environment, each implementation may have different performance results. By default, this is set to YES to use the JVM implementation.


A.7.2 Data Synchronoization Tracing and Logging

Data Synchronization uses a log engine that supports the following parameters for logging:

  • GLOBALLogger

  • SYNCLogger

  • MGPLogger

  • MGPAPPLYLogger

  • MGPCOMPOSELogger

Each parameter sets up a logger for a component which you can use to specify the trace level, trace type, trace destination, trace file pool size, trace file size, and trace users in the following sample format.

XLogger=TRACE_LEVEL=<trace_level>|TRACE_TYPE=<trace_type[,trace_type...]>|TRACE_DESTINATION=<trace_destination>[|TRACE_FILE_POOL_SIZE=<trace_file_pool_size>|TRACE_FILE_SIZE=<trace_file_size>|TRACE_USER=<trace_users>]

Note:

  • Separate each parameter with the '|' symbol. Separate values with a comma ','.

  • If there are any invalid values in the definition, the whole definition is ignored.

  • For each logger, the trace level, type, and destination parameters are mandatory.

  • The parameters TRACE_FILE_POOL_SIZE and TRACE_FILE_SIZE are only applicable for the GLOBALLogger only.

  • If you define the LOCAL_CONSOLE, then you must also define SYNCLogger and GLOBALLogger.

Table A-8 lists the parameters for each logger.

Table A-8 Acceptable Parameter Values

Parameter Description

TRACE_LEVEL

Trace Level parameter can be set to the following trace message levels:

MANDATORY: This option logs mandatory messages only. For example, Program Exceptions. Regardless of component settings, this option logs exceptions in the error log file (err.log) located in the Conslog directory.

WARNING: This option logs warning messages and messages at the Mandatory level. For example, Program Exceptions that users can ignore, messages that the program wants to warn the users with, and so on.

NORMAL: This option logs normal messages that the user must be informed with and messages at the Mandatory and Warning level.

INFO: This option logs information messages and messages at the Mandatory, Warning, and Normal levels.

Examples:

  • Timing of synchronization: When the SYNCLogger is set to the TRACE_TYPE=TIMING and TRACE_LEVEL=INFO.

  • MGP Apply: When the MGPAPPLYLogger is set to the TRACE_TYPE=TIMING and TRACE_LEVEL=INFO. MGP Apply must be started with Timing of. COMPOSE must be started with Timing of MGP Compose. MGP must be started with Timing of.

  • COMPOSE: When the MGPAPPLYLogger is set to the TRACE_TYPE=TIMING and TRACE_LEVEL=INFO.

  • Status of MGP: When the MGPLogger is set to the TRACE_TYPE=GENERAL and TRACE_LEVEL=INFO.

CONFIG: This option logs configuration messages and messages at the Mandatory, Warning, Normal, and Info levels. For example, JDBC driver version.

FINEST: The finest level. This level is used for developers only.

ALL: This option logs all messages according to the other settings such as Trace Type and Users.

TRACE_TYPE

SQL: This option logs SQL-related messages only. For example, SQL statements. Note: This option is not trace level sensitive.

TIMING: This option logs timing data only. Note: This option is trace level sensitive. For MGP Cycle time and Synchronization time, use the Trace Level INFO option. If the MGPLogger is set to TIMING and INFO, it will log the MGP Cycle time. If the SYNCLogger is set to TIMING and INFO, it logs the synchronization time.

DATA: This option logs data only. Note: This option is not trace level sensitive. This option prints all data with any trace level other than the OFF option.

RESUME: Messages dealing with Reliable Transport have a RESUME trace type. This option only logs messages with Reliable Transport. Note: This option is not trace level sensitive. This option prints all the RESUME trace type messages with any trace level other than the OFF option.

FUNCTION: This option displays the program flow by logging methods such as Entry, Exit or Invoke. For Long methods, this option logs the method's entry or exit; which is a simple invoke log. Note: This option is not trace level sensitive. This option prints all the FUNCTION trace type messages with any trace level other than the OFF option.

GENERAL: This option logs messages that do not belong to any of the above listed trace types. Note: This type is trace level sensitive.

ALL: This option generates logs of all trace types.

TRACE_DESTINATION

The Administrator can set this parameter to any of these destinations: LOCAL_CONSOLE or TEXTFILE. The Console option generates trace output to the Console screen. The TEXTFILE option generates trace output to a file. See also TRACE_FILE_SIZE, and TRACE_FILE_POOL_SIZE.

Sample Value: TRACE_DESTINATION=TEXTFILE

TRACE_FILE_POOL_SIZE=2

The default value is 2. This parameter specifies the number of files in the trace file pool. If the pool limit is reached, the trace output is overwritten to the first file in the pool. See also TRACE_FILE_POOL_SIZE.

TRACE_FILE_SIZE=1

Used as the maximum file size in MB for trace files. If the value is about to be reached, the trace feature generates output to the next trace file in the pool. For more information, see TRACE_FILE_POOL_SIZE.

TRACE_USERS

List of valid user names. The listed user trace information and system trace information is generated as output. If the value is an empty string "", then every user is traced.


The new log engine does not support the parameters that have been used in the old log engine. They are:

  • TRACE_ENABLE

  • TRACE_REMOTE_PORT

  • TRACE_REMOTE_MACHINE

  • TRACE_FILE_PER_USER

  • TRACE_FILE_NAME

  • TRACE_REMOTE_HOST