On Monday, February 6, 2017 at 6:18:02 PM UTC-5, Bert JW Regeer wrote:
Don’t touch request.session… > I wish! We have to do a read for login status and some other things. Pushing that into a secondary session was an option, but that's gone. Could create a pass-through session factory that won’t call into redis > session unless a key is being set (access thus won’t create a session, so > you can do things like ‘key’ in blah). > >> That is a brilliant idea! > As it currently stands, it doesn’t look like redis sessions plays well > with transactions, IMHO, that is a good thing. Sessions can store transactional-dependent data via multiple writes and a callback. A lot of times we store data in a session that is important to have regardless of transaction status -- like 3rd party calls that are not transaction aware or the last-5 page views. based upon a quick glance at the code it looks like it refreshes/persists > data the moment you set it. >From what I recall, it serializes the session and calls SET on every writes and sends an EXPIRE on most other operations. The amount of traffic was hurting our installation. The fork I wrote (pyramid_session_redis) registers a callback to call set/expire only once. I've nearly got a solution in place for this. It was harder to write because I am avoiding a rewrite. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/a66ec562-df52-47fe-bc9c-c728fe889498%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
