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 Core Server uses a central db.have table to track the have list 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 Core Server uses client-specific db.have.pt tables that are independent of the central db.have table. 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.pt table? Journaled, checkpointed, and recoverable? 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.

Replication

Replication is supported for the client types that are journaled, checkpointed, and recoverable.

Between Commit Servers and Edge Servers, only the client spec is replicated. To learn more, see Setting global client views in Client workspaces and client views.

Converting client types

The following tables indicates which client types can be converted to another client 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

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.

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

You can also minimize contention to a central have list 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 readonly commands, are:

A partitioned-jnl workspace supports all the same commands as a writeable workspace, but with the additional benefit of a have list 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 independent db.have.pt table by setting the client.readonly.dir server configurable. For example:

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

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. Helix Core 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.