[sqlalchemy] Re: Multiple sessions
Just to close my question: I tweaked few settings for innodb and seems pretty good already. The biggest is being: transaction_isolation = READ-COMMITTED Of course not for everyone but for my needs, this works perfectly. thanks On Thursday, June 27, 2013 8:36:51 PM UTC-7, Srini wrote: I guess my question should have been how do I handle consistent non locking reads as app server is reverse proxied and each request goes to different session. thanks On Thursday, June 27, 2013 8:11:38 PM UTC-7, Srini wrote: Hi, I am using tornado, sqlalchemy behind ngnix in reverse proxy mode. I run 4+ app servers and each maintaining it's own db session and connection. I am seeing the same problem as mentioned in the forum. One session creates new data and other session doesn't get updated information. As I am behind reverse proxy, each user request could go to different session all together. https://groups.google.com/forum/#!searchin/sqlalchemy/multiple$20sessions/sqlalchemy/MqeoIcRAdwM/egleUsQ6z-8J How can I avoid this? I am using InnoDB. thanks -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
[sqlalchemy] Re: Multiple sessions
I guess my question should have been how do I handle consistent non locking reads as app server is reverse proxied and each request goes to different session. thanks On Thursday, June 27, 2013 8:11:38 PM UTC-7, Srini wrote: Hi, I am using tornado, sqlalchemy behind ngnix in reverse proxy mode. I run 4+ app servers and each maintaining it's own db session and connection. I am seeing the same problem as mentioned in the forum. One session creates new data and other session doesn't get updated information. As I am behind reverse proxy, each user request could go to different session all together. https://groups.google.com/forum/#!searchin/sqlalchemy/multiple$20sessions/sqlalchemy/MqeoIcRAdwM/egleUsQ6z-8J How can I avoid this? I am using InnoDB. thanks -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
[sqlalchemy] Re: Multiple Sessions
Thanks for pointing me there, Michael. Wasn't aware of that InnoDB feature. Make all sense, now. On Aug 13, 12:37 am, Michael Bayer mike...@zzzcomputing.com wrote: On Aug 12, 2010, at 7:36 AM, Erich Eder wrote: I've found a strange behaviour when using multiple sessions: A committed change to an object in one session does not get reflected in the other session, even after a session.expire_all() (or expire() or refresh() on the object. In fact, even an explicit query does not retrieve the changed data. I'm using MySQL. Further investigation showed that it happens only with InnoDB. Using MyISAM produces the expected results. Looks like a caching issue with InnoDB. its not caching, its transaction isolation, which is why expire_all() is not the issue here (and why expire_all() is not really needed by itself with autocommit=False - rollback() and commit() handle it). at the end, session1 is still open in its second transaction which has loaded a1.data as 123. http://dev.mysql.com/doc/refman/5.0/en/innodb-consistent-read.html -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
