# Session Handling via Datenbank defekt seit upgrade von 5.5.10 auf 5.6.4 **URL:** \ **Category:** Administration\ **Created:** [8. März 2020 um 22:29 UTC](https://forum.shopware.com/t/session-handling-via-datenbank-defekt-seit-upgrade-von-5-5-10-auf-5-6-4/65330 "2020-03-08T22:29:59Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![das\_knopfloch](https://avatars.discourse-cdn.com/v4/letter/d/839c29/32.png) [@das\_knopfloch](https://forum.shopware.com/u/das_knopfloch)\ **Post date:** [8. März 2020 um 22:29 UTC](https://forum.shopware.com/t/session-handling-via-datenbank-defekt-seit-upgrade-von-5-5-10-auf-5-6-4/65330/1 "2020-03-08T22:29:59Z")
Hallo shopware-Team,   wir haben seit dem upgrade von 5.5.10 auf 5.6.4 ein arges Problem mit den Sessions.   Die Datenbank blockiert für 50 Sekunden (default für lock-timeout), wenn die sessions aufgeräumt werden sollen (egal ob per cron oder per gc). Dann bricht es ab mit einem Fehler (siehe unten). Die Anzahl der Einträge scheint nicht relevant zu sein, hatte zum Schluss alles gelöscht aus der s\_core\_session was nicht in den letzten 10 Minuten editiert wurde (übrig blieben 1.800 Einträge) und es war dennoch nicht möglich die Sessions aufzuräumen. Selbst das umstellen via config.php auf aufräumen per cron scheint nicht einwandfrei zu gehen (session.gc\_probability = 0). Trotz dieser Einstellung blockierte die Datenbank alle ~20 Sekunden um die Sessions zu löschen (via SHOW PROCESSLIST kontrolliert). Erst als ich gc\_divisor auf 1.000.000 gestellt hatte, gab es keine Aufrufe mehr. Über eine lange Zeit habe ich heute in der Datenbank einfach per kill den Prozess „DELETE FROM s\_core\_session …“ nach spätestens 10 Sekunden Laufzeit gelöscht, um den shop zumindest einigermaßen am laufen zu halten. Mir schien es am Ende so, dass keine Transaktion offen sein darf (= aktiver Seitenaufruf auf der Webseite sein darf), da sonst es mit hoher Wahrscheinlichkeit zu einem dead-lock kommen kann. Sprich sw:session:cleanup bekommt kein lock, da eine andere Transaktion noch nicht beendet ist und ebenfalls ein INSERT INTO auf die s\_core\_session machen möchte (und dort ebenfalls wartet auf den lock). Was halt auffällt: mit 5.5.10 lief noch alle einwandfrei!   Uncaught PDOException: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction in …   Randnotiz: Alle x male klappt das Aufräumen der Sessions allerdings innerhalb von 0,04 Sekunden.   Randnitiz 2: Selbst wenn keine Session gelöscht wird, (kontrolliert mit SELECT COUNT(\*) FROM s\_core\_session) wird angezeigt, dass eine Session entfernt wurde (einfach mehrfach den cron hintereinander ausführen). $ php bin/console sw:session:cleanup                                                                                                                  [OK] Successfully removed 1 expired sessions                                                                                                                         SETUP: Debian 9.12 PHP 7.3.15 MariaDB 10.3 ---
**Author:** ![raymond](https://avatars.discourse-cdn.com/v4/letter/r/c57346/32.png) [@raymond](https://forum.shopware.com/u/raymond)\ **Post date:** [9. März 2020 um 07:13 UTC](https://forum.shopware.com/t/session-handling-via-datenbank-defekt-seit-upgrade-von-5-5-10-auf-5-6-4/65330/2 "2020-03-09T07:13:05Z")
Ich blicke nicht bei den Changelog durch, aber es gibt bereits 5.6.6. Welche SQL Server Version wird verwendet? ---
**Author:** ![das\_knopfloch](https://avatars.discourse-cdn.com/v4/letter/d/839c29/32.png) [@das\_knopfloch](https://forum.shopware.com/u/das_knopfloch)\ **Post date:** [9. März 2020 um 17:12 UTC](https://forum.shopware.com/t/session-handling-via-datenbank-defekt-seit-upgrade-von-5-5-10-auf-5-6-4/65330/3 "2020-03-09T17:12:46Z")
Ich habe das Setup nachgetragen.   Das Shopware 5.6.6 raus ist habe ich gesehen und die changelogs kontrolliert (ich habe nichts gefunden zu dem Thema session). Installieren werde ich das die Tage auch und dann auf Redis oder Memcache für die Session wechseln. Jetzt bestände noch die Möglichkeit diesen Bug zu tracen, sofern interesse daran seitens Shopware besteht. ---
**Author:** ![Moritz\_Naczenski](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/moritz_naczenski/32/7792_2.png) [@Moritz\_Naczenski](https://forum.shopware.com/u/Moritz_Naczenski)\ **Post date:** [9. März 2020 um 17:20 UTC](https://forum.shopware.com/t/session-handling-via-datenbank-defekt-seit-upgrade-von-5-5-10-auf-5-6-4/65330/4 "2020-03-09T17:20:28Z")
Memcache würde ich nicht verwenden, nimm lieber Redis. Memcache führt häufig dazu, dass sporadisch die Sessions nur sehr langsam vergeben werden. Wurde hier damals als Issue dokumentiert bei Memcache: [Session lock record with PHP 7.0.9 · Issue #269 · php-memcached-dev/php-memcached · GitHub](https://github.com/php-memcached-dev/php-memcached/issues/269) Glaube dein Problem wird aber nicht das Session-Handling sein. Shopware nutzt per Default ein Session Locking, wenn also mehrere Schreibzugriffe auf die Session stattfinden, kann das Locking greifen. Also scheinen bei dir die Zugriffe auf die Session ja zugenommen zu haben. Das kann verschiedenste Ursachen haben - natürlich auch im Core. Das Session Locking kannst du auch per config.php deaktivieren: [config.php settings](https://developers.shopware.com/developers-guide/shopware-config/#session-locking)