Concurrent Transaction Processing

Several applications or users often need to share the same data source. This sharing can lead to problems if they try to access a record concurrently, that is, if they try to process the same data source record at the same time.

To ensure the integrity of a data source, concurrent transactions must execute as if they were isolated from each other. The changes of one transaction to a data source must be concealed from all other transactions until that transaction is committed. To do otherwise, runs the risk of open transactions being exposed to interim inconsistent images of the data source, and consequently, corrupting the data source.

To prevent users from corrupting the data in this way, the database management system (DBMS) must coordinate concurrent access. There are many strategies for doing this. No matter which type of data source you use, Maintain Data respects your DBMS concurrency strategy and lets it coordinate access to its own data sources.

For more information about how your DBMS handles concurrent access, see your DBMS documentation. For FOCUS data sources, this information is presented in Ensuring Transaction Integrity for FOCUS Data Sources. For DB2, you can find some suggested strategies for writing Maintain Data transactions to DB2 data sources in Ensuring Transaction Integrity for DB2 Data Sources. For many other types of data sources, you can also apply the strategies described in Ensuring Transaction Integrity for DB2 Data Sources, changing DBMS-specific details when necessary.

Example: Why Concurrent Access to a Data Source Must Be Managed Carefully

Consider the following two applications that access the Employee data source:

The Promotion application reads a list of employees who have received promotions, and updates their job codes to correspond to their new positions.
The Salary application, run once at the beginning of each year, checks every employee job code and gives each employee an annual raise based on his or her job title. For example, assistant managers (job code A15) will earn $30,000 in the new year, and managers (A16) will earn $40,000.

Joan Irving is an assistant manager. Consider what happens when these two applications try to access and update the same record at the same time, without any coordination:

The Promotion application reads the record of Irving and, based on information in a transaction data source, indicates that she has been promoted to manager, and computes her new job code (A16).
The Salary application reads the record of Irving and, based on her job code in the data source (A15), computes her new salary ($30,000).
The Promotion application writes the new job code (A16) to the data source.
The Salary application writes the new salary ($30,000) to the data source.

Remember the earlier business rule (assistant managers earn $30,000, managers earn $40,000). Because two applications accessed the same record at the same time without any coordination, the rule has been broken (Joan Irving has a manager job code but the salary of an assistant manager). The data source has become internally inconsistent.