Vedran Pavic

For completeness and discoverability, here are the issues that have been marked as duplicate of this one: - #676 - #1027 - #1083 - #1583 And to some degree also...

Hi @alexandrececchin, thanks for the confirmation. I've experimented a bit with different approaches the last couple of days, but unfortunately haven't found a way to address this problem without making...

> I'll open an issue to consider doing a more substantial makeover of the session clean-up job. For reference, I've created #1739.

IIRC, according to different user reports we had involving deadlocks, it's not necessary to have more than one instance running bulk delete statement. > Can that also couse a problem...

Thanks for the report @aterleto. > This breaks consistency with the cached session attributes and creates an orphan in the Redis database. Furthermore, upon fail-over if the session is re-hydrated...

@eleftherias I'm not a fan of this being addressed at the expense of performance i.e. with additional round trips to Redis. Was there a real issue with attributes being nulled...

That fact that attributes were nulled out is IMO an internal implementation detail of Redis backed session stores, and the most optimal approach in terms of keeping number of calls...

Good timing on bringing this up - I was just preparing the PR to revert this yesterday so that it doesn't fall through the cracks while waiting on feedback on...

A session with 4 session attributes is stored in Redis as a single hash, whereas in a relational database it's stored as 5 records (1 for the core session data...

I forgot to mention one more thing - don't forget that number of records in session attributes table directly impacts performance. If by _rather than combining it with the update...