Change 5119
Added -t delay in an attempt to ensure transactional atomicity.
If no additional journal entries are written during this delay,
the transaction is assumed complete, which closes the pipe, which
terminates the command (which if includes a p4d -jr, releases the
locks in the target server, allowing commands access to the
replicated atomic transaction). By default, this delay
is ten milliseconds.
Locking the journal does not ensure transactional atomicity since
the server locks the journal once for each journal entry written,
not once per transaction. And we would like to avoid locking the
journal since that would introduce a potential concurrency problem.
Not all operations in the server are atomic transactions and
therefore cannot be replicated atomically. For example, updating
a client's have list as files are being synced is not an atomic
transaction. But committing a submit is an atomic transaction,
and this change (with perhaps some site-specific tuning of
the -t delay) attempts to replicate the commit atomically.
If no additional journal entries are written during this delay,
the transaction is assumed complete, which closes the pipe, which
terminates the command (which if includes a p4d -jr, releases the
locks in the target server, allowing commands access to the
replicated atomic transaction). By default, this delay
is ten milliseconds.
Locking the journal does not ensure transactional atomicity since
the server locks the journal once for each journal entry written,
not once per transaction. And we would like to avoid locking the
journal since that would introduce a potential concurrency problem.
Not all operations in the server are atomic transactions and
therefore cannot be replicated atomically. For example, updating
a client's have list as files are being synced is not an atomic
transaction. But committing a submit is an atomic transaction,
and this change (with perhaps some site-specific tuning of
the -t delay) attempts to replicate the commit atomically.