Support > Repository > Model > Lock method

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 -
  • Update data (release lock at the end of transaction)
  • Display menu screen
  • Log off (including session timeout)

The behavior of pessimistic lock on the update screen is explained by "screen function> update".

You can select the lock method from "Screen> Other> Database Details".

Figure 1 Selection of locking method

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.

The item name entered here is not displayed in the "model item" column, but it is internally managed.Therefore, you do not need to define this item in the "Model item" column.

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.

Both Pessimistic Lock and Optimistic Lock can be enabled.If you only use one side, please uncheck the other one.

Points to note when using submodels

Keep the consistency between the main model and the submodel for the locking method.

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.

Normally it is a pessimistic lock

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 it is better to select optimistic lock

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.

Implement optimism lock

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.)

Implementation of pessimistic lock

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.]

About the database SELECT FOR UPDATE syntax

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.

  1. Open the update screen.(SELECT the data here.)
  2. The user edits the data.
  3. The data is updated by pressing the save button.(UPDATE the data.)

Transactions are different in 1. and 3. here.Processing that spans multiple transactions in this manner is generally treated as "long transaction".

It is different from database 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.

"The execution of" SELECT ... FOR UPDATE "immediately after pressing the save button ..." can not prevent lost updating and can not be said to be a strict pessimistic lock.

In Wagby, these long transactions keep consistency, so we support both optimistic locks and pessimistic locks (using our own lock managers).

Revision of pessimistic lock manager 7.12

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.

Definition method

Enable "Environment> Customize> Detail> Store lock information in database table".

Figure 2 Store lock information in database table

Search lock information

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.

Figure 3 Search lock information

Jfclockobject table

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.

Acquire lock from the outside

By adding lock information (record) from the external program to the jfclockobject table, you can prevent editing from the Wagby screen.

Please make sure that there is no lock target data in the table beforehand and add records.

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.