Wagby allows you to choose an optimistic locking method and a pessimistic locking method.
In WagbyIn model unitsYou can specify the locking method.The standard is a pessimistic lock. The difference between the two is as follows.
|Optimistic lock||Pessimistic lock (standard)|
|Characteristic||Multiple users can open the same data update screen at the same time.Only the first updater succeeds in writing.All other updates will fail.||Only one user can open the same data update screen.Other users can view the data, but can not open the update screen.|
|Write conflict||Once you have canceled the update screen, you need to go back to the update screen again.The data being modified will be invalid.||In terms of the mechanism of operation, writing conflict does not occur.Until the first user completes the update, other users will wait for update processing.|
|Response at competition||Even if a conflict occurs and the update fails, since the input data remains on the screen, the user can devise the recovery processing by the user.For example, it may be possible to temporarily copy the entered value to a text editor or the like and update it again.||The user who opens the update screen prepares a certain time limit for keeping the screen in an updated state for a long time.This is called session timeout.Wagby's standard is 20 minutes.You can change it with "environment> application> initial parameter".|
|How to achieve lock||Prepare the item "version control column" in the model.The type is an 8-byte integer.When the update screen is opened, the value of the same item is read.The value is read again at the time of update processing, and if it is not changed from the first read value, the update is successful.||We use Wagby's internal "lock manager".When you open the update screen, you get the lock.Release the lock at the end of the update.|
|Timing of lock release||-||
You can select the lock method from "Screen> Other> Database Details".
Optimistic locks and pessimistic locks need to choose either one.The standard is pessimistic lock.(Pessimistic lock is checked, and input is disabled.)
If you enable the optimistic lock checkbox, you can enter the pessimistic lock checkbox and version control column name.An item of type "8 byte integer" is automatically added with the item name entered here.
Mandatory check of column name for version management is done.When focus is set in the uninput state, an error message "This value is required" is displayed.
For example, if optimistic locking is enabled for only submodels, it will result in an error trying to use a version control column that does not exist in the main model.
Wagby's standard is "pessimist lock".Even if you are not conscious of this setting, it will be operated as a pessimist lock.Because there is no conflict, it is the least troublesome method.
When considering cooperation with an external system, it may be better to use optimistic locking.
Pessimistic locks use lock managers Wagby prepared internally.For this reason, special measures are needed to let the external system know which data is locked now.
Optimistic locking allows Wagby and external systems to share version control columns provided in the database.Even if it is updated from either system, conflicts can be detected reliably.
We use the function provided by middleware called Hibernate that Wagby uses.However, it adopts the version method only, not the time stamp method.(We determined that the time stamping method is not strict.)
We use Wagby's own lock manager.The key at lock acquisition is held in memory.You can also manage the lock key with the special internal table jfclockobject.In this case, you can know "which record is locked" from the external system.[Details are explained in the next section.]
Several databases provide the "SELECT ... FOR UPDATE" syntax.But Wagby's lock does not use this function.I will explain the reason.
"SELECT ... FOR UPDATE" is a lock that is valid only within a transaction. However, the locking process described in this section is accompanied by user's operation, and the following operation is required.
Transactions are different in 1. and 3. here.Processing that spans multiple transactions in this manner is generally treated as "long transaction".
For long transactions, "SELECT ... FOR UPDATE" can not be used. This syntax is not screen processing, it is assumed to be used in certain business processing logic.
In Wagby, these long transactions keep consistency, so we support both optimistic locks and pessimistic locks (using our own lock managers).
As of R7.12, we have a revised version (v2) of class LockManagerImpl that manages lock objects in memory when pessimism lock is used.It improves run-time performance when a large amount of lock processing occurs.From v7.12 this v2 will be used as a standard.[Revert to old method ...]
Wagby's "pessimistic lock" has a lock manager inside.This lock manager keeps locks in memory.This information can not be known from the outside.
We have an option to write this lock information in a (relational database) table.This makes it possible to know "which data is locked" from the external program, so you can control that the locked data is not updated.
Furthermore, by locking from the external program side, it is also possible to control so that Wagby side can not update it.
Enable "Environment> Customize> Detail> Store lock information in database table".
Log on as a system administrator and open the "Lock information search" screen on the management processing tab, the currently locked data is displayed as shown in Figure 3.
If you enable the setting in Figure 2, the jfclockobject table is prepared in the relational database to be used.
|item name||Primary key||Description|
|modelname||○||Model name to be locked (English)|
|pkey||○||The value of the primary key of the data to be locked.In the case of a compound key, concatenate the value with "$SEP" as a delimiter.|
|lockForAll||○||Numeric type."1" locks individual data."2" means locking of the entire model.|
|userid||The userid value (of the juser account) that got the lock.|
|username||The username value (of the juser account) that got the lock.|
|sessionid||The session ID value of the user who acquired the lock.|
At the timing of opening a data update screen, search the jfclockobject table and check whether there is a lock on the relevant data.If the lock already exists, the update screen can not be opened.If it does not exist, write lock information to the same table.Delete the lock information at the timing when update processing is completed.
By adding lock information (record) from the external program to the jfclockobject table, you can prevent editing from the Wagby screen.
Prepared in the jfclockobject tableFill in all the columnsit is necessary.If either one is not set (null), no lock is acquired.
The items modelname, pkey, lockForAll are required to point to the target data.
The items userid, username, and sessionid are necessary to record the information "who got the lock".
The item sessionid stores the session ID issued by the web application server.However, when setting this value from an external program, it is difficult to generate a session ID.For example, when Tomcat is used as the web application server, the session ID is a random character string of 32 characters.As a rule, if it is a unique character string it will work.
When setting values from an external program, it is a good idea to decide some rules.For example, this value should be as follows.
By setting a pseudo session ID character string based on such a rule, it becomes easier to see who locked it while maintaining the uniqueness.