Ensuring Transaction Integrity for FOCUS Data Sources

In this section:

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 as the Simultaneous Usage (SU) facility on some platforms.)

To ensure transaction integrity for FOCUS data sources, perform the following tasks:


Top of page

x
Setting COMMIT

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 procedure.



x
Syntax: How to Set COMMIT

The COMMIT server parameter enables transaction integrity for FOCUS data sources. To set COMMIT, issue the SET COMMIT command in a WebFOCUS Server's 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 procedure, use the following syntax

SYS_MGR.FOCSET("COMMIT""{ON|}"

where:

ON

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.

OFF

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.


Top of page

x
Sharing Access to FOCUS Data Sources

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 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, in which 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.


Top of page

x
How the FOCUS Database Server and Change-verification Work

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:

  1. As always, use the NEXT or MATCH commands to retrieve the data source records you need for the current transaction. When the application issues these commands, the server sends the application a private "client" copy of the records.

    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.

  2. When the application issues a data source write command (such as INCLUDE, UPDATE, REVISE, or DELETE) against the retrieved records, it updates its private copy of the records.
  3. When the application issues a COMMIT command to indicate the end of the transaction, the application session sends a log of the transaction back to the server. The server now checks to see if any of the segments that the transaction changed have, in the interim, been changed and committed to the data source by other clients, and if any segments that the transaction added have, in the interim, been added by other clients. (You can customize which segments the FOCUS Database Server checks for changes by setting the PATHCHECK server parameter, as described in Selecting Which Segments Will Be Verified for Changes.)

    The server takes one of the following actions:

    • No conflict. If none of the records has been changed or added in the interim, then the transaction is consistent with the current state of the data source. The server writes the transaction to the data source and sets the application's FocCurrent transaction variable to zero to confirm the update.
    • Conflict. If any records have been changed in the interim, then the transaction might be inconsistent with the current state of the data source. The server ignores the transaction changes to the data source, rolling back the transaction, and alerts the application by setting FocCurrent to a nonzero number.
  4. The application evaluates FocCurrent and branches to the appropriate function.

Top of page

x
Selecting Which Segments Will Be Verified for Changes

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 How to Set PATHCHECK server parameter.

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:



x
Syntax: How to Set PATHCHECK

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:

ON

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.

OFF

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.


Top of page

x
Identifying the FOCUS Database Server

How to:

To identify which FOCUS Database Server will manage access to a given FOCUS data source, you must issue a How to Identify a FOCUS Database Server With USE command that associates the server with the data source.

You can issue the How to Identify a FOCUS Database Server With USE command:



x
Syntax: How to Identify a FOCUS Database Server With USE

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's syntax is:

USE 
datafile ON server_id 
[datafile ON server_id]
.
.
.
END

where:

datafile

Is the file specification of a data source to be managed by the FOCUS Database Server.

server_id

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/server pairs in one USE command.


Top of page

x
Using Report Procedures and a FOCUS Database Server

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's records. This ensures that the transaction sees a consistent image of the data source that is isolated from changes being attempted by other users.

WebFOCUS procedures, such as report procedures, are not part of a logical transaction; when control passes from a Maintain procedure to a WebFOCUS procedure, the open transaction is suspended for the duration of the WebFOCUS procedure. Therefore, if the WebFOCUS 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 WebFOCUS procedures containing report requests to a WebFOCUS Server that also hosts Maintain procedures, you must represent the server as two different outbound nodes, and deploy WebFOCUS reporting procedures to one node and Maintain procedures to the other node, as described in Accessing Report Procedures When Using a FOCUS Database Server. Otherwise, the WebFOCUS procedures may interfere with your transaction logic.


Top of page

x
Accessing Report Procedures When Using a FOCUS Database Server

How to:

Reference:

If you are using a FOCUS Database Server and you wish to access Maintain procedures and WebFOCUS report procedures that are located on the same WebFOCUS Server (referred to here as the target server), you must:

  1. Represent the target server as two different outbound nodes. Represent it this way to:
    • WebFOCUS Developer Studio.
    • Each WebFOCUS Server that executes Maintain procedures and/or WebFOCUS procedures that are located on the target server.

    This requirement also applies to the target server itself: if it executes Maintain procedures and/or WebFOCUS procedures that are deployed on itself, it must be represented to itself as two outbound nodes.

  2. Of the procedures that you will be deploying to the target server, deploy the WebFOCUS report procedures to one of these outbound nodes, and deploy the Maintain procedures to the other outbound node.

This is necessary because deploying both types of procedures to the same outbound node can cause report logic to corrupt transaction integrity.



x
Procedure: How to Access Maintain and WebFOCUS Report Procedures on the Same Server

In an application that uses a FOCUS Database Server, if you want to deploy to the Maintain procedures of the application and WebFOCUS report procedures on the same WebFOCUS Server (referred to here as the target server):

  1. Represent the target server to WebFOCUS Developer Studio as two outbound nodes that have different remote server names but the same protocol options (for the TCP/IP protocol, this means specifying the two nodes with the same IP address, port number, and compression setting).

    For more information, see the Creating Reporting Applications With Developer Studio manual.

  2. Represent the target server to WebFOCUS Servers as two outbound nodes. Perform this step for each WebFOCUS Server that executes Maintain procedures and/or WebFOCUS procedures that are deployed on the target server. This requirement also applies to the target server itself: if it executes Maintain procedures and/or WebFOCUS procedures that are deployed on itself, it must be represented to itself as two outbound nodes.

    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 in the WebFOCUS Server Communications Configuration File Location and Name 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 block's other values unchanged.

    If the WebFOCUS Server is the target server, then copy the target server node block from WebFOCUS Developer Studio odin.cfg file (located in the webfocusdesktop_root_dir\srv71\wfs\etc directory), and paste it, twice, into the target server's communications configuration file. Edit the second pasted block to provide a new eight-character node name, but leave the block's other values unchanged.

    For information about the name and location of the server's communications configuration file, see Communications Configuration File Location and Name.

  3. Deploy the application.

    For information about deploying applications, see Partitioning and Deploying Project Files in the Creating Reporting Applications With Developer Studio manual.



x
Reference: Communications Configuration File Location and Name

The WebFOCUS Server communications configuration file under:


Top of page

x
Sharing Data Sources With Legacy MODIFY Applications

A FOCUS data source being managed by a FOCUS Database Server can be accessed by both WebFOCUS Maintain applications and legacy MODIFY applications. Note that while MODIFY allows creating records with duplicate keys, WebFOCUS Maintain does not support FOCUS data sources that have duplicate keys.


WebFOCUS