Now, consider another situation when both these users (John and Tom) have to update two text files. While an update is in progress, a GT.M LOCK should prevent the other user from LOCKing that file. In some cases, a deadlock occurs when both users cannot move forward because they do not release their current LOCKs before adding additional LOCKs.
A deadlock situation can occur in the following situation:
John Tom LOCK +file_1 LOCK +file_2 LOCK +file_2 LOCK +file_1
Here both the users are deadlocked and neither can move forward. Note that a deadlock situation does not actually block the underlying resource.
Let us now create this situation.
At the GT.M prompt of John, execute the following commands:
GTM>set file1="file_1.txt" GTM>lock +file1 GTM>open file1:APPEND GTM>use file1 GTM>write "John",! GTM>close file1
Note that John has not released the LOCK on resource "file1".
At the GT.M prompt of Tom, execute the following commands:
GTM> set file2="file_2.txt" GTM> lock +file2 GTM> open file2:APPEND GTM> use file2 GTM>write "Tom",! GTM>close file2
Note that Tom has not released the LOCK on resource "file2".
Now, at the GT.M prompt of John, execute the following commands.
GTM>set file2="file_2.txt" GTM>lock +file2
The latter command attempts to acquire a lock on resource
file2
that is already locked by Tom.
Therefore, this results in a deadlock situation. Repeat the same
process for Tom and attempt to lock resource
file1
.
Execute the following command at LKE prompt to view this deadlock situation.
LKE>show -all -wait file1 Owned by PID= 2080 which is an existing process Request PID= 2089 which is an existing process file2 Owned by PID= 2089 which is an existing process Request PID=2080 which is an existing process
This shows a deadlock situation where neither user can proceed
forward because it is waiting for the other user to release the lock.
You can resolve this situation by clearing the locks using the
LKE CLEAR -PID
command.
![]() | |
Avoid using the |