Locking Models

System

The client has asked me to justify the choice of Sumbit Locking model. It is the only locking model I have ever worked with and someone told me that it is the most frequently used. I am trying to understand the documentation (ts.552.admin.win.pdf around p.73). Am I just not understanding, is this not accurate, does this need a rewrite or do these not seem like adequate options?

Is the following quote at all true and if so, in what versions/environments/locking models? At least in my Windows 2000/TeamSite 5.5.2/Submit Locking environment, any user other than that which locked a file in the workarea is prompted that the file is locked to another user, even if they edit the file in the same workarea, or if they have previously modified the file.

"When a file is locked, it is locked for a particular workarea. That is, all users who have access to that workarea can edit the file. In addition, all users who have previously modified the file can edit it in their workareas (but not lock it)."

Does anyone use something besides submit locking, and if so, why and how does it work out? With Optional Write Locking, why would you ever allow someone to edit a file without locking it? With mandatory write locking, why would you want the user to be able to continue to edit after releasing the lock?

Locking Models
TeamSite supports three different types of file locking:
- Submit Locking
- Optional Write Locking
- Mandatory Write Locking
A branch’s locking model is set when it is created (for more information, see the TeamSite User’s Guide).
Different branches on one TeamSite server may use different types of locking. All workareas on a
branch use the same type of locking.
When a file is locked, it is locked for a particular workarea. That is, all users who have access
to that workarea can edit the file. In addition, all users who have previously modified the file
can edit it in their workareas (but not lock it).
Submit Locking
Submit locking means that if a file is locked, only users within the workarea where it is locked
may submit the file to the staging area. Users are still allowed to edit the file within the context
of other workareas but may not submit it until the user who holds the lock has submitted his
version or manually released the lock.
If a file is not locked, anyone may submit it.
If someone else has the lock on a file that a user is editing, and the user tries to submit a
workarea or directory containing his version after the lock holder has submitted the file and
released the lock, the Compare Results window will appear showing the conflicting versions
of the file. From this window, the user can choose to merge the two files, or to overwrite the
version in the staging area with his own.
If someone else has locked a file, and a user edits it through the TeamSite GUI, the following
warning is displayed:
Managing Access
The user can continue to edit the file, but will have to merge the changes with those of the lock
owner after it is submitted.
Write Locking
Write locking means that a locked file may only be edited in the workarea where it is locked.
Users in other workareas may not edit the same file even within the context of their own
workareas, but they may view a read-only copy if they have the necessary permissions. Write
locking may be optional, in which case users may choose whether or not to lock the files that
they edit, or mandatory, in which case users cannot edit a file without locking it first. Under
Mandatory Write Locking, all files in a workarea are read-only until a user locks them for editing.
Once a user modifies a file while holding a lock, the user will be able to continue to modify the
file even after releasing the lock. Once the user submits the file, it will become read-only again.
If a user edits an unlocked file, and somebody edits the file at the same time but in a different
workarea, the second person to submit the file to the staging area will have a conflict and will
need to either merge the two versions, overwrite the version in the staging area with his own,
or overwrite his own version with the version in the staging area (see the TeamSite User’s Guide for
details).