Locking in Web Applications
Locking in Web applications behaves differently from non-Web applications because fields cannot be locked in a browser. Uniface maintains the data integrity of Web applications using a CRC checksum. You can use the error triggers to influence the behavior of the application after a data conflict occurs. You can also maintain the integrity using the U_VERSION field.
- Optimistic locking—optimistic locking is feasible in Web environment. If multiple users modify the same data simultaneously, the modification made by one user is stored. The error triggers are fired for modified occurrences of the other users.
- Cautious locking—cautious locking is not feasible because server pages are stateless. This means that the Web Application Server is unaware of data modifications until the browser submits the modified page to the server. In a Web application, Cautious locking behaves in the same way as an Optimistic locking.
- No Updates locking—no updates locking prevents
data from being updated. Users can modify data in the browser but the data is not stored in the
database. When Uniface handles a request and finds that data is modified, it ignores the
modification and fires the error trigger for the modified occurrences. If the locking property
of an entity is set to
No Update, you can set the syntax of all its fields to not editable (NED) to prevent users from editing the fields in browsers. - Paranoid locking—if you want to use paranoid locking, you must ensure rollback and commit follow each transaction to release locks and commit the data. You can code this in the postActivate trigger.
