From 5509730380cabd01c5bfd1a9fac40a26bc48bdb5 Mon Sep 17 00:00:00 2001 From: Andrii Havryliuk Date: Wed, 21 Jan 2026 17:44:06 +0100 Subject: [PATCH 1/3] add session deadlocks workaround guide --- .../guidelines/troubleshooting/performance.md | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/resources/guidelines/troubleshooting/performance.md b/resources/guidelines/troubleshooting/performance.md index fc9c497d9..6b605fec9 100644 --- a/resources/guidelines/troubleshooting/performance.md +++ b/resources/guidelines/troubleshooting/performance.md @@ -38,3 +38,24 @@ Also consider changing the `indexing-behavior` to your needs if you need to sync Another reason for high memory usage might be the logging within the application. See the logging section in the [performance guide](../../../guides/hosting/performance/performance-tweaks#logging) for more information. After all, you still can make use of tools like blackfire.io to find the root cause of the memory usage. + +### Session Deadlocks with file-based sessions + +If you experience request timeouts or hanging requests in environments using file-based sessions (common in shared hosting), you might be encountering a session deadlock. This occurs when two concurrent processes create a circular lock dependency: one process holds the session file lock while trying to acquire the cache lock, another holds the cache lock while trying to acquire the session lock (ABBA deadlock pattern). + +Symptoms include: + +* Requests randomly timing out under load +* PHP processes stuck in "waiting" state +* Issues appearing only under concurrent requests + +The recommended solution is to [use Redis for sessions](../../../guides/hosting/performance/session), which eliminates the file-based locking conflict. +If Redis is not available in your environment, you can work around the issue by disabling cache stampede protection (option available since Shopware 6.7.7.0). + +```yaml +shopware: + cache: + disable_stampede_protection: true +``` + +This option only takes effect when file-based sessions are detected. Be aware that disabling stampede protection may increase backend load when multiple requests simultaneously try to regenerate the same expired cache entry. For most shops, this trade-off is acceptable compared to deadlock issues. From ef9cf8ea0f8ea09a41d916a709790955cb16a49c Mon Sep 17 00:00:00 2001 From: Andrii Havryliuk Date: Wed, 21 Jan 2026 17:50:26 +0100 Subject: [PATCH 2/3] update doc --- resources/guidelines/troubleshooting/performance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/resources/guidelines/troubleshooting/performance.md b/resources/guidelines/troubleshooting/performance.md index 6b605fec9..c38426061 100644 --- a/resources/guidelines/troubleshooting/performance.md +++ b/resources/guidelines/troubleshooting/performance.md @@ -41,7 +41,7 @@ After all, you still can make use of tools like blackfire.io to find the root ca ### Session Deadlocks with file-based sessions -If you experience request timeouts or hanging requests in environments using file-based sessions (common in shared hosting), you might be encountering a session deadlock. This occurs when two concurrent processes create a circular lock dependency: one process holds the session file lock while trying to acquire the cache lock, another holds the cache lock while trying to acquire the session lock (ABBA deadlock pattern). +If you experience request timeouts or hanging requests in environments using file-based sessions (common in shared hosting), you might be encountering a session deadlock. This occurs when two concurrent processes create a circular lock dependency: one process holds the session file lock while trying to acquire the cache lock, another holds the cache lock while trying to acquire the session lock. Symptoms include: From f9360a9a01cdc720d637af74c2d45791e41e4267 Mon Sep 17 00:00:00 2001 From: Andrii Havryliuk Date: Wed, 21 Jan 2026 17:56:27 +0100 Subject: [PATCH 3/3] fix syntax in other file to make pipeline pass --- concepts/framework/http_cache.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/concepts/framework/http_cache.md b/concepts/framework/http_cache.md index ece6497e1..892144292 100644 --- a/concepts/framework/http_cache.md +++ b/concepts/framework/http_cache.md @@ -97,7 +97,7 @@ This is because all data loaded in a Storefront controller is loaded in the core List-type routes are not tagged with all entities returned in the response. This applies to Store API endpoints such as product listings or search results, category listings, or SEO URL listings. These routes instead rely on their TTL as defined by the active HTTP Caching Policy. If the default TTLs are not appropriate for your use case, configure a [custom caching policy](../../guides/hosting/performance/caches.md#fine-tuning-per-route-or-app-hook) for those routes. The reason is that, while it would be technically possible to try to invalidate all affected listings when a single entity changes, doing this at scale is very costly in terms of performance and resources. One entity can appear in many different listings (with different filters, sorting, pagination, etc.). It is also not possible to catch all cases where a change would cause an entity to newly appear in or disappear from a cached listing. Because of this, listing pages cannot guarantee strict, immediate consistency under caching; instead, we accept a small amount of staleness in exchange for predictable performance and stability. Since v6.7.7.0, cache invalidations logging at info level can be enabled or disabled via the `tag_invalidation_log_enabled` configuration option. -It is disabled by default. +It is disabled by default. ```yaml # /config/packages/shopware.yaml