Screen Procedure Design Recommendations |
Virtual Machine |
 |
To efficiently support a large number of concurrent users, a transaction-processing application should not perform user-input during a transaction. Applications that are designed to comply with this restriction cannot hold any locks while waiting for user-input. Mainframe system software has explicit support for such applications (referred to as 'pseudo-conversational' operation in CICS) and the performance advantage is considerable.
A series of user-inputs and the resulting coordinated alterations to shared application data are perceived as a single screen procedure by the end-user. However, the screen procedure may consist internally of several transactions that occur after specific user inputs. Only a transaction that follows the last user-input of the screen procedure may alter shared application data (otherwise the alterations cannot be coordinated by the transaction processing environment).
An application that does not hold locks across user-input must allow for the possibility of concurrency errors (for example two users changing or deleting the same shared data). The application should detect such errors within the transaction that applies changes to the shared data. A common technique is to re-read records retrieved earlier in the screen procedure, verifying that they still exist and the contents have not changed.
Deferring all alterations to the end of a screen procedure has the additional advantage that no writes to shared data need be reversed if a user chooses to abandon a screen procedure prior to completion. During extensive or complex screen procedures, applications can store input in work files or other non-shared storage. When concurrency errors arise, the application can let the user edit the stored input in order to retry the transaction rather than requiring it to be re-entered.
When shared data must be reserved for use by one user, and while that user is performing input then an application can use its own 'lock file'. Records are usually inserted and deleted to correspond with lock acquisition and release. The application determines the conventions for using this technique and all affected parts of the application must follow the convention. The application must also be able to clean up the lock file if necessary in the event of process or system failures.
Topic ID: 720206