Client workspace types

Performance might benefit from the use of client workspaces of type readonly, partitioned, or partitioned-jnl.

When to use which type

  • By default, clients are created with the type writeable, and the Type field is not shown in the spec.

  • The Helix Server uses a central db.have table to track the have listClosed The list of file revisions currently in the client workspace. for writeable clients. However, when many clients syncing a large number of files at the same time, the central table is subject to contention.

  • Other client types can reduce this contention because, for them, Helix Server uses independent db.have tables, each of which pertains only to one client instance.

  • To enable this feature, an administrator uses the client.readonly.dir configurable to set the location on the server for the independent db.have tables.

Type Independent db.have? Eligible for journal, checkpoint, and recovery? Use Case
writeable No Yes

For general use.
partitioned-jnl Yes Yes For general use in situations where client workspaces might otherwise experience contention for the server's central db.have table.
readonly Yes No For short lived clients used in build automation scripts that do not edit or submit files.
partitioned Yes No

For short lived clients used in build automation scripts that do edit or submit files.
graph No Yes

For use with depots and repos of type graph and Git Connector. To learn more, see Work with Git.
Note

The types that are eligible for journaling, checkpointing, and recovery also support Replication, except that between commit and edge servers, only the client spec is replicated. To learn more, see Setting global client views in Client workspaces and client views.

The following restrictions apply if you want to convert a client workspace to a different type.

  To writeable To graph To readonly To partitioned To partitioned-jnl
From writeable Not applicable If no open files and not a stream client Not allowed Not allowed Not allowed
From graph If no open files  Not applicable Not allowed Not allowed Not allowed
From readonly Not allowed Not allowed Not applicable Allowed Allowed
From partitioned Not allowed Not allowed If no open files  Not applicable Allowed
From partitioned-jnl Not allowed Not allowed If no open files  Allowed Not applicable

To make one of the allowed conversions, update the Type field in the client specification. See p4 client > Options > -T type in Helix Core Command-Line (P4) Reference.

Limitations and capabilities

Clients of type readonly, partitioned, and partitioned-jnl are allowed to be unloaded and reloaded. The deletion entries and notes are journaled for partitioned-jnl but not for readonly or partitioned.

The p4 journaldbchecksums command works for partitioned-jnl but not for readonly or partitioned because this command updates journal entries.

readonly, partitioned, and partitioned-jnl support the p4d -xx, p4 dbverify, and p4d -xv commands, which read, but do not update, the tables.

Tip

You can also minimize contention to a central have listClosed The list of file revisions currently in the client workspace. by using the Commit-edge architecture because each edge server has its own db.have table that is separate from the commit server's central db.have table.

Typical commands and readonly, partitioned, and partitioned-jnl clients

readonly partitioned partitioned-jnl

For build automation, where editing and submitting files is not required, consider readonly workspaces. Typical commands run from a readonly workspace:

Use partitioned workspaces for the same purpose as readonly workspaces, but with the additional ability to edit and submit files. Typical commands run from a partitioned workspace, in addition to the the readonly commands, are:

A partitioned-jnl workspace supports all the same commands as a writeable workspace, but with the additional benefit of a have listClosed The list of file revisions currently in the client workspace. that is independent of the server's central db.have table. Unlike readonly and partitioned, partitioned-jnl is eligible for journaling, checkpointing, and recovery.

 

Creating a readonly, partitioned, or partitioned-jnl client workspace

Before creating a client workspace of type readonly, partitioned, or partitioned-jnl, configure the storage location for the local db.have table by setting the client.readonly.dir server configurable. For example:

p4 configure set client.readonly.dir=part-db-have

Note

Although the name of this configurable contains "readonly", its setting applies to the readonly, partitioned, and partitioned-jnl types.

Relative paths specified in client.readonly.dir are relative to P4ROOT, but absolute paths can also be specified. The client.readonly.dir server configurable does not require a server restart. The Helix Server creates the directory upon first usage if it doesn't already exist.

To create a client workspace that is readonly, partitioned, or partitioned-jnl, set the Type field in the client specification to readonly, partitioned, or partitioned-jnl.

For example,

p4 client my-readonly-client
...
Type: readonly

or

p4 client my-partitioned-client
...
Type: partitioned

or

p4 client my-partitioned-jnl-client
...
Type: partitioned-jnl

Commands for partitioned have tables

The p4d -jd command also works with partitioned db.have tables. See Journal dump and restore filtering.