Thanks for your comments.
I'm using sqlite in default mode (which is synchronous) and here's my engine configuration. engine = create_engine('sqlite:///my_db.sqlite', connect_args={'detect_types': sqlite3.PARSE_DECLTYPES| sqlite3.PARSE_COLNAMES}, native_datetime=True, poolclass=NullPool, convert_unicode=True ) metadata.create_all(engine) # this factory is thread safe: a session object is returned (always the same) to the # caller. If called from another thread, the returned session object will be different session_factory = sessionmaker(bind=engine, expire_on_commit=False) self.session_maker = scoped_session(session_factory) What I cannot understand is that session.commit() in P1 does not seem to actually write on disk as my reader process (P2) queries the db, ie: P2 does not rely on a value stored in its own session: it queries the db to get something up to date (via session.query(...)) When explicitely closing the session just after the commit (session.close() just after the session.commit()), everything works. If a session.close() is needed to actually write to db, I cannont understand the neet to commit... I may be missing something... On Monday, January 20, 2014 5:56:31 PM UTC+1, Klauss wrote: > > On Mon, Jan 20, 2014 at 1:51 PM, Richard Gerd Kuesters > <ric...@humantech.com.br <javascript:>> wrote: > > i was having this kind of problem while using a multi-threaded app, but > with > > a postgres backend. > > > > in postgres, with high-concurrency, i was expecting this kind of > behaviour, > > so i had to implement some simple semaphores to make it work properly -- > > sqlalchemy is not to blame if something changes in your database while > one > > end of a software creates a record that the another doesn't knows about > when > > trying to operate on. > > I think it may have something to do with the implicit transaction the > session opens when manipulated. > > P2 may be holding on to an older snapshot. > > I'd suggest committing right before checking to see whether the > records are there in P2, just as an experiment. The right behavior > would be to commit after any kind of session manipulation, though > that's trickier (lots of things count as implicit session > manipulations). > -- 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.