Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.1

# 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 P4 Server uses a central `db.have` table to track the have list The list of file revisions most recently synced from the depot into the workspace. In other words, the list of files that the client workspace has. 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, P4 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 | If no open files | Allowed | Allowed
From graph | If no open files | Not applicable | Not allowed | Not allowed | Not allowed
From readonly | Allowed | Not allowed | Not applicable | Allowed | Allowed
From partitioned | Allowed | Not allowed | If no open files | Not applicable | Allowed
From partitioned-jnl | 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 database tables.

You can also minimize contention to a central have list The list of file revisions most recently synced from the depot into the workspace. In other words, the list of files that the client workspace has. by using the commitCommit-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: p4 clean p4 flush p4 status p4 sync p4 update | 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: p4 add p4 edit p4 integ p4 reconcile p4 shelve p4 submit p4 unshelve | A `partitioned-jnl` workspace supports all the same commands as a `writeable` workspace, but with the additional benefit of a have list The list of file revisions most recently synced from the depot into the workspace. In other words, the list of files that the client workspace has. 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. P4 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.

Your search for returned results