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
> <[email protected] <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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/groups/opt_out.
