X-Cross offers an advanced and fully functional record locking. The lock of the record is not on the single table, but for all the complex object (e.g an invoice, and order, ect.) that can be composed of multiple tables.
The record locking is one of the features of an ERP that more often are underestimated, but can cause problems.
Optimistic locking
In the optimistic locking, the conflict can occur, but it is detected at write time, checking if, between the read and the write of the data, some changes have been performed by another user. This approach can be acceptable working on single table (even if the applied modification will be lost), but it is not enough when the user modifies complex objects, e.g an invoice or another commercial document.
Pessimistic locking
This type of record lock is much safer, but still there are two problems:
- Detect the moment in which the editing starts
- Working on complex multilevel objects
Detect the moment in which the editing starts
In meny ERPs, the user, if enabled, enters the data window always in enter data model, i.e. the fields are always enterable and modifiable. The intention to update the database is shown later, using some type of “save” command, like it happensa in a word processor or in a spreadsheet. So, how can the program know if a window is opened only to read data, or to modify a record? In this situation, the pessimistic record locking is almost impossible.
In X-Cross, instead, the windows are always opened in display mode, and the fileds are not enterable.
The user, in the window, can insert a new record or modify the existing record, calling a command. In this moment, and not before, X-Cross re-reads the data, and at the same time applies a lock to the record.
Working on complex multilevel objects
Another problem that is very common is when a complex object is being edited.
For eample, imagine an invoice, that is composed at least of a header and one or more lines. If a new line is inserted, from the point of view of the database a new record is inserted in the invoice lines table, but in reality tha invoice is modified.
In this case, the optimistic locking on the invoice lines is totally ineffective, since no line is modified. The pessimistic locking is therefore mandtory, but this suffers of the problem of detecting the moment in which editing starts, so it is seldom possible.
Update of multilevel objects in a single transaction
In addition to what already exposed, the locking on complex objetcts not only requires pessimistic lock, but also the insert-update of the whole object must happen in the same transaction. This is exactly how X-Cross works: all the updates, insert and deletes of a single multilevel complex object are executed in the database in a single transaction.
“Orphans” locks
A common problem, with the pessimistic locking, is the possibility to leave “orphans” locks that are not used any more. For example, if a computer crashes or is suddendly switched off, the record locks acan remain active in the database.
To avoid this problem, X-Cross in every transaction checks all the orphan locks, whose session is not active any more, and deletes them.