mod_dav_svn Apache connection pool vs svnserve Berkeley DB locks for burst concurrency

Direct answer

mod_dav_svn does not have a Subversion connection pool. Its acceptance boundary is Apache's MPM: how many workers or threads may run and how many pending connections the listen socket will accept. In Apache 2.4 that is primarily MaxRequestWorkers, constrained by ServerLimit and ThreadsPerChild, with ListenBacklog controlling the pending-connection queue. In Apache 2.2 the same role was played by MaxClients, so verify the deployed httpd version before applying guidance.

svnserve with Berkeley DB also has no Subversion lock pool. Its capacity boundary is the Berkeley DB DB_ENV lock region, configured through repository DB_CONFIG parameters such as set_lk_max_lockers, set_lk_max_locks, and set_lk_max_objects. Cache sizing is a separate resource; lock-table exhaustion is the concurrency boundary. When transaction volume exceeds those capacities, the failure is a Berkeley DB lock-resource failure, not an Apache worker failure.

The Subversion Book documents these boundaries separately for each server and backend. It does not provide a universal formula or decision criterion for choosing between Apache MPM tuning and Berkeley DB lock tuning under burst load. Subversion does not expose a unified pooling API; exhaustion handling is explicitly delegated to httpd process management and to Berkeley DB environment configuration.

Confirmed boundaries vs likely explanation

Confirmed from the documented architecture: the two systems fail at different layers. mod_dav_svn can reject or queue connections before Subversion work begins if Apache cannot schedule a worker or if the backlog is full. svnserve with Berkeley DB can accept the connection and then fail inside the repository environment if lock tables are exhausted.

A likely explanation for burst symptoms is that OS limits—file descriptors, process caps, or MPM sizing—make one boundary appear to be the other. An Apache worker ceiling can look like repository slowness, while a Berkeley DB lock failure can look like generic I/O or memory pressure. Also, svnserve's invocation mode—inetd, standalone daemon, or SSH tunnel—changes how OS process and thread limits interact with repository locks. Confirm the actual failing layer before resizing either system.

Check only what changes the recommendation

1. Confirm the server and backend: svn --version and svnadmin info /path/to/repo. Berkeley DB is a legacy backend; the Book recommends FSFS for new repositories, so BDB tuning is mainly for existing deployments.
2. For mod_dav_svn, identify the active MPM and run configuration: apachectl -M and apachectl -t -D DUMP_RUN_CFG; on some distributions the command is apache2ctl. Then inspect the Apache error log for worker exhaustion or backlog messages.
3. For svnserve with Berkeley DB, inspect the repository's db/DB_CONFIG and Berkeley DB environment statistics to compare current lock, locker, and object counts against configured maximums.
4. Reproduce the burst on a staging host while watching the Apache scoreboard and Berkeley DB lock-region usage to see which boundary is reached first.

Do not raise set_lk_max_* values or Apache worker limits until the specific failure is confirmed; increasing the wrong boundary can hide the real constraint and increase memory or file-descriptor pressure.

One diagnostic detail that changes the advice

Which boundary is actually failing under burst: Apache worker or backlog exhaustion, or Berkeley DB lock-region exhaustion? If it is Apache, tune MPM and OS limits; if it is Berkeley DB, tune DB_CONFIG lock capacity or migrate the repository to FSFS.