Each database management system (DBMS) supports transaction integrity in its own way. The FOCUS DBMS manages concurrent access to FOCUS data sources using the FOCUS Database Server, and uses certain commands to identify transaction integrity attributes. The FOCUS Database Server was formerly known as a sink machine, or Simultaneous Usage (SU) facility on some platforms.
To ensure transaction integrity for FOCUS data sources, perform the following tasks:
|
How to: |
You must set the COMMIT server parameter to ON before using the COMMIT and ROLLBACK commands for FOCUS data sources, and before using the FOCUS Database Server. You must set COMMIT on all WebFOCUS Servers hosting procedures that read or write to FOCUS data sources in a logical transaction. In most applications, this will mean setting COMMIT on all WebFOCUS Servers that host procedures with data source commands.
You can set COMMIT:
If you set COMMIT in a user profile or group profile, you must set it in the profile of the user or group that runs the application.
You can also set COMMIT directly from a Maintain Data procedure.
The COMMIT server parameter enables transaction integrity for FOCUS data sources. To set COMMIT, issue the SET COMMIT command in a WebFOCUS Server global profile, or in one or more of its user or group profiles, using the following syntax:
SET COMMIT={ON|OFF}
To set COMMIT in a Maintain Data procedure, use the following syntax
SYS_MGR.FOCSET("COMMIT" "{ON|OFF})"
where:
Enables the COMMIT and ROLLBACK commands for use with FOCUS data sources, and enables the use of the FOCUS Database Server to ensure transaction integrity.
Disables the COMMIT and ROLLBACK commands for use with FOCUS data sources, and disables the use of the FOCUS Database Server to ensure transaction integrity. OFF is the default value.
The FOCUS DBMS ensures transaction integrity when multiple users are trying to access the same data source concurrently. If you are processing a transaction and, in the interval between beginning your transaction and completing it, the segments updated by your application have been changed and committed to the data source by another user, Maintain Data will roll back your transaction. This coordination is performed by the FOCUS Database Server. You can test if your transaction was rolled back by checking the value of the FocCurrent transaction variable, and then branch accordingly.
This strategy, where FOCUS verifies that the records to which you wish to write have not been written to by another user in the interim, is called change verification. It enables many users to share write access to a data source, and grants update privileges for a given record to the first user that attempts the update.
Change verification takes advantage of the fact that two users rarely try to update the same record at the same time. Some DBMSs use strategies that lock out all but one user. Others grant update privileges to the first user that retrieves a record, even if he or she is the last one ready to update it, resulting in a performance bottleneck. In contrast, the FOCUS DBMS strategy of change verification enables the maximum number of users to access the same data concurrently, and makes it possible to write the maximum number of transactions in the shortest time. The FOCUS Database Server and change verification strategy are designed for high-performance transaction processing.
The change verification strategy of the FOCUS Database Server is an extension of basic transaction processing. Each application user who accesses the FOCUS Database Server is known as a client. To ensure transaction integrity follow this simple change verify protocol:
Note: Do not retrieve data from a data source by running a report procedure. The FOCUS Database Server does not check this data for changes when you attempt to commit a transaction.
The server takes one of the following actions:
|
How to: |
When you use a FOCUS Database Server, you can customize the change verification process by defining the segments for which the FOCUS Database Server will verify changes. You define this, using the server parameter described in PATHCHECK.
You can choose between:
You can set PATHCHECK for each FOCUS Database Server, which affects all applications that access FOCUS data sources managed by that FOCUS Database Server. To set it under:
The PATHCHECK server parameter defines which segments the FOCUS Database Server will check for changes. To set PATHCHECK, issue the SET PATHCHECK command in the batch file that starts the FOCUS Database Server, using the following syntax
SET PATHCHECK={ON|OFF}
where:
Instructs the FOCUS Database Server to verify that all segments in the path extending from the root segment to the target segment have not been changed and committed in the interim by other users. This is the default for OS/390 and MVS.
Instructs the FOCUS Database Server to check only segments that the current transaction has updated or deleted, and verify that those segments have not been changed and committed in the interim by other users. This is the default for Windows and UNIX.
|
How to: |
To identify which FOCUS Database Server will manage access to a given FOCUS data source, you must issue a command that associates the server with the data source, as described in USE.
You can issue this command:
For each FOCUS data source that will be managed by a FOCUS Database Server, you must associate the data source with the server by issuing a USE command in a WebFOCUS Server profile. The USE command syntax is:
USE datafile ON server_id [datafile ON server_id] . . . END
where:
Is the file specification of a data source to be managed by the FOCUS Database Server.
Under Windows and UNIX, is the node name of the FOCUS Database Server, as defined in the FOCUS Database Server node block of the Data Server configuration file.
Under OS/390 and MVS, is the ddname of the communication dataset that points to the FOCUS Database Server job.
If you wish, you can identify multiple data source and server pairs in one USE command.
When a FOCUS Database Server manages access to a FOCUS data source, each logical transaction that accesses that data source works with its own private copy of the data source records. This ensures that the transaction sees a consistent image of the data source that is isolated from changes being attempted by other users.
App Studio procedures, such as report procedures, are not part of a logical transaction. When control passes from a Maintain Data procedure to an App Studio procedure, the open transaction is suspended for the duration of the App Studio procedure. Therefore, if the App Studio procedure reports against a FOCUS data source, it accesses the live data source. It does not open the private copy of the transaction. Changes made by the open transaction are not seen by the report, and changes committed by other users since the open transaction began are seen by the report, though not necessarily by the open transaction.
For similar reasons, you should not use a report procedure to retrieve data for use in a transaction. The FOCUS Database Server does not check this data for changes when you attempt to commit a transaction. Always use the NEXT or MATCH commands to retrieve transaction data.
If you wish to deploy App Studio procedures containing report requests to a WebFOCUS Server that also hosts Maintain Data procedures, you must represent the server as two different outbound nodes, and deploy App Studio reporting procedures to one node and Maintain Data procedures to the other node, as described in Accessing Report Procedures When Using a FOCUS Database Server. Otherwise, the App Studio procedures may interfere with your transaction logic.
|
How to: |
|
Reference: |
If you are using a FOCUS Database Server and you wish to access Maintain Data procedures and App Studio report procedures that are located on the same WebFOCUS Server (referred to here as the target server), you must:
This requirement also applies to the target server itself. If it executes Maintain Data procedures or App Studio procedures that are deployed on itself, it must be represented to itself as two outbound nodes.
This is necessary because deploying both types of procedures to the same outbound node can cause report logic to corrupt transaction integrity.
In an application that uses a FOCUS Database Server, if you want to deploy to the Maintain Data procedures of the application and App Studio report procedures on the same WebFOCUS Server (referred to here as the target server):
As in step 1, define the two outbound nodes as having different remote server names but the same protocol options (for the TCP/IP protocol, this means specifying the same IP address, port number, and compression setting). You can do this by copying the target server node block, as described in the WebFOCUS Server communications configuration file, and paste it just below the end of the original block. The node block begins with the NODE keyword and continues through the END keyword. Edit the pasted block to provide a new eight-character node name, but leave the other values unchanged.
If the WebFOCUS Server is the target server, then copy the target server node block from the App Studio odin.cfg file and paste it twice, into the communications configuration file of the target server. Edit the second pasted block to provide a new eight-character node name, but leave the other values of the block unchanged.
For information about the name and location of the communications configuration server file, see Communications Configuration File Location and Name.
The WebFOCUS Server communications configuration file under:
When you install and configure a WebFOCUS Server, the configuration directory defaults to $HOME/ibi/srv82/server_instance under UNIX, and home\ibi\srv82\server_instance under Windows. HOME is an environment variable whose value in this context is the name of the home directory of the user account that installed the WebFOCUS Server. server_instance is the name of a server configuration directory (there is one directory per server instance. The convention is to name this directory wfs for a WebFOCUS Server, and wfm for a Maintain Data Application Server).
A FOCUS data source being managed by a FOCUS Database Server can be accessed by both Maintain Data applications and legacy MODIFY applications. Note that while MODIFY allows creating records with duplicate keys, Maintain Data does not support FOCUS data sources that have duplicate keys.