Exception: Unable to obtain lock for session (retry in 30s)

[PawelGIX]

I experience issue when viewing my page.

So sorry… Error: Exception: Unable to obtain lock for session (retry in 30s) (in wire/modules/Session/SessionHandlerDB/SessionHandlerDB.module line 96)

#0 [internal function]: SessionHandlerDB->read('fj818rmpnqntp4f...')
#1 wire/core/Session.php (330): session_start(Array)
#2 wire/core/Wire.php (413): Session->___init()
#3 wire/core/WireHooks.php (968): Wire->_callMethod('___init', Array)
#4 wire/core/Wire.php (484): WireHooks->runHooks(Object(Session), 'init', Array)
#5 wire/core/Session.php (205): Wire->__call('init', Array)
#6 wire/core/ProcessWire.php (602): Session->__construct(Object(ProcessWire))
#7 wire/core/ProcessWire.php (316): ProcessWire->load(Object(Config))
#8 index.php (52): ProcessWire->__construct(Object(Config))
#9 {main}

This error message was shown because: site is in debug mode. ($config->debug = true; => site/config.php). Error has been logged.

Do you have any idea why this is happening?

ProcessWire 3.0.246 © 2026

[PawelGIX]

I disabled ProcessSessionDB but I still get this error

[ryancramerdesign]

This is session locking doing its job rather than a bug, though the message doesn't explain itself well.

SessionHandlerDB takes a MySQL GET_LOCK for the session when a request starts reading it, and holds it until that request finishes. This is deliberate: it stops two concurrent requests for the same session from writing over each other's session data. If a second request for the same session arrives while the first still holds the lock, it waits — and if it waits too long, you get the exception you're seeing, along with an HTTP 429 and a Retry-After header.

So something in another tab, window, or background request on the same session was still running and holding that lock.

One detail the message gets confusing: the "retry in 30s" is the Retry-After hint sent to the client, not how long it waited. The actual wait is the module's lockSeconds setting, which defaults to 50 seconds. So the request that was holding the lock had been running for over 50 seconds, not 30. That is a long time for a single request, which is worth knowing — it points at something specific rather than general slowness.

On disabling ProcessSessionDB: that explains why it made no difference. Those are two separate modules that happen to live in the same folder:

• SessionHandlerDB — the actual session handler, and the thing doing the locking
• ProcessSessionDB — only the admin screen for browsing active sessions

Disabling the viewer has no effect on the handler. If you want to stop using database sessions entirely, it's SessionHandlerDB that needs uninstalling, after which ProcessWire falls back to file-based sessions, which don't use this locking mechanism.

Typical causes of a request holding the lock that long: a large import or export, a slow external API call in a hook or template, a $pages->find() over a very large result set, a long-running admin action, or a stalled request that hasn't timed out yet. Anything that keeps a request alive while the same browser session makes another request.

Both lockSeconds and retrySeconds are configurable in the SessionHandlerDB module settings if you want to adjust the tolerance — though raising lockSeconds treats the symptom rather than the cause.

One question before closing this, because the answer changes whether it's expected or not:

Does this happen occasionally, and can you associate it with something slow running at the time? If so it's working as designed, and the fix is to shorten whatever that operation is.

Or does it happen frequently, or on ordinary page views with nothing long-running? In that case something is holding a lock for 50+ seconds that shouldn't be, and that is worth digging into further.

-Claude