#616010 (Bug #64576, #64577) ** Improved concurrency through lockless reads. This release benefits from a new type of perforce lock known as 'peeking'. When 'peeking' is enabled many common commands no longer block other commands attempting to update tables. Consistency is applied through a new counter 'maxCommitChange' obtained at the beginning of each command and through client entity locks, which are fine-grain unique client locks that prevent concurrent read/write access to an individual client.
A slightly different table lock-order is used with 'peeking' enabled, this is due to requirements when multiple tables are accessed with a mixture of read and peek. Also, submit is broken into 2 transactions, the first is the update to key tables (i.e. the bulk of the submit) the second is an update to the submitters client data, this reduces the overall update lock time for a submit.
Lockless reads are enabled when starting the server with the command line option '-vdb.peeking=2' or by the configurable 'db.peeking' followed by a server restart.
e.g. 'p4 configure set db.peeking=2' (needs server restart).
0 disabled (default)
1 new lock-order / entity locks (diagnostic only)
2 peeking enabled (hx/dx optimization on)
3 peeking enabled (hx/dx optimization off)
A typically installation would run with peeking set to 2, the value 3 is only intended for certain repositories as it carries a trade-off between concurrency and command completion speed. If your repository has many revisions per file then setting a value of 3 may cause some commands to complete slower but will not require read locks on the db.revhx/db.revdx tables.
List of commands that run lockless (peeking enabled):
annotate, branches, changes, clients, counters, depots, diff, diff2, dirs, filelog, files (-a) fixes, fstat (peeking=3), have, interchanges, integ, integed, istat, jobs, keys, labels, merge, streams, sizes (-a), sync (peeking=3), print (-a), resolved, users
List of commands that run partial lockless (peeking enabled):
copy, cstat, fstat, interchanges (copy), istat (copy), opened, sync
NOTE: With 'peeking' server.locks.dir can no longer be disabled, that is because these locks are required for client consistency. If you are a customer who has disabled this in the past due to problems with syncs, you can turn-off the longer duration lock by setting server.locks.sync=0.
#685514 ** This release has made changes to the way that 'p4 sync' manages its memory consumption. For all cases memory usage has been reduced (up to 50% for initial syncs and forced refresh).
#662490 ** Due to the heavy reliance on server.locks for better concurrency the default value for spec.hashbuckets has been changed to 99. Typically this value has already been increased from its previous default of zero.
#736593 (Bug #69548) ** p4 resolve' no longer crashes when attempting to handle database records with invalid file charset values.
#723545 (Bugs #69286, #69288) ** An update command submitted via a forwarding replica which is interrupted while it is waiting for replication processing to complete will no longer cause unnecessary system resource usage in the forwarding replica.
#716980 (Bug #68870) ** On a case-insensitive server, the 'p4 server' command was incorrectly allowing the creation of two separate server specs with ServerIDs that differed only in case. Additionally, the 'p4 servers' command was displaying the list of server specs in case-sensitive sorting order on a case-insensitive server, and the 'p4 configure show <serverid>' command was only showing configuration variables for the server which matched exactly in case. Starting with this change, case-insensitive servers will process the ServerID value using case-insensitive matching. Due to the new database format introduced with this release, a restore from checkpoint is required. On a case-insensitive server, this restore will have the following effects on the existing server specs: 1) If there are multiple server specs with ServerIDs that differ only in case, all but one of those server specs will be deleted; only the last server spec will be retained. 2) The sort order of the existing server specs will be repaired, so that the 'p4 servers' command now displays them in case-insensitive sort order. If you are operating a server in case-insensitive mode, then prior to upgrading to this release, you should run 'p4 servers' and see if you have multiple server specs for the same case-insensitive ServerID. If you do, use 'p4 server -d' to delete the unwanted server specs before checkpointing and restoring your database, to ensure that the correct server spec is retained.
Important note: Please refer to: http://www.perforce.com/perforce/r13.2/user/relnotes.txt to get up to date GA and post-GA information about this release.