Ok, Michael, That helped a lot, what i have done is (for future reference/others);
1) turned of autoflush on all sessions, 2) shortened the lifespan of session to a minimum, 3) removed the "if object_session(obj): session.merge(obj)" option in the Session() function, This seems to have solved the problem for now (needs more testing)! Thanks for the link to the talk as well. Cheerio, Lars On Saturday, February 1, 2014 4:34:10 PM UTC+1, Michael Bayer wrote: > > > On Feb 1, 2014, at 9:01 AM, lars van gemerden > <la...@rational-it.com<javascript:>> > wrote: > > > Oh, on more question: > > > > might there be anything inherently wrong with the scoped_session > approach that i showed in the code snippets above? > > the code which illustrates the @contextmanager and the “def Session()” > looks error-prone and entirely awkward, and the rationale for such a > context manager isn’t apparent. > > It appears to be mixing the intent of wishing to share random rows between > multiple sessions (a bad idea) while at the same time trying to conceal the > details of how a delicate operation like that is performed (it guesses > whether add() or merge() should be used, etc). It also seems to mix the > concerns of dealing with object mechanics and session creation at the same > time which are typically two different concerns, not to mention that it has > a complex system of committing or not committing using flags which makes it > unsurprising that you’re seeing non-existent rows show up in other > transactions. > > So yeah, if it were me, I’d definitely try to approach whatever the > problem is it’s trying to solve in a different way, one which preferably > sticks to the patterns outlined in the ORM tutorial as much as possible > (e.g. one session at a time, load/manipulate objects, commit(), throw > everything away). Those points at which an application actually uses two > sessions at once, or transfers objects between them, should be very > isolated cases with very explicit mechanics and clear rationale why this > operation is needed in this specific case (where typical cases are: sending > objects into worker threads or processes, moving objects in and out of > caching layers, or running two transactions simultaneously so that one can > commit and the other roll back, such as a transaction writing to an > application history table). The app wouldn’t have a generic “here’s one > of those places we need to use two sessions with a specific target object > to pull out of one of them” use case such that a context manager is needed, > there should be extremely few places where that kind of thing goes on. > > The kind of issue you’re hitting is exactly the one I talk about in detail > in my talk, “The SQLAlchemy Session in Depth”: > http://techspot.zzzeek.org/2012/11/14/pycon-canada-the-sqlalchemy-session-in-depth/ > Page 18 of the PDF illustrates a slide “Lack of Behavioral Constraints > Creates Confusion” illustrating an anti-pattern similar to the one I think > we’re seeing here. > > -- 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.
