Locking and unlocking are treated just like any other operation in the context of a transaction. For example, consider the following series of operations:
begin
lock
do A
save
do B
save
unlock
commit
In this example the lock and unlock have no effect. This series of operations is equivalent to:
begin
do A
save
do B
save
commit
The reason for this is that changes to a workspace are only published (that is, made visible to other Sessions) upon commit of the transaction, and this includes changes in the locked status of a node. As a result, if a lock is enabled and then disabled within the same transaction, its effect never makes it to the persistent workspace and therefore it does nothing.
In order to use locks properly (that is, to prevent the “lost update problem”), locking and unlocking must be done in separate transactions. For example:
begin
lock
commit
begin
do A
save
do B
save
unlock
commit
This series of operations would ensure that the actions A and B are protected by the lock.