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.
strangely, though, was this to happen with sqlite. are you using it in
synchronous mode? journaling is enabled? are you using the default pool
for connection?
best regards,
richard.
On 01/20/2014 02:12 PM, pr64 wrote:
Hi,
Strange behaviour with sqa in multi-process environment... already
posted on StackOverflow
<http://stackoverflow.com/questions/21109794/delayed-change-using-sqlalchemy>
for a web app but still missing some understanding so posting here.
I've created an application where my "sqa calls" are encapsulated: My
API's methods always do the same kind of stuff:
1- request a session
2- do my stuff - mainly requesting the db through session.query(...)
3- eventually:
- modify some mapped object attributes
- and write to db (session.commit()).
Several consecutive calls to my API's methods return the same session
object as long as I'm in the same thread which is the required
behaviour. Some commits happen but the session is always the same
(expire_on_commit = False)
# 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)
session_maker = scoped_session(session_factory)
# to get a session:
session = session_maker()
If I fork another thread, using the API is still safe since the first
step (getting a session) will return a new session instance (due to
scoped_session)
Here's my problem:
I have two processes which such an architecture (based on this API).
While P1 is writing to DB (session.commit()), P2 is reading from it
(session.query(...)). The problem is that P2 does not see the DB
change and has to poll several times before getting it. I'm actually
requesting the DB through session.query(...) calls from P2 but nothing
happens. *Sometimes it works though! :-(* Don't know why (did not
change the code) -> Over 10 times, it will work 3 times...
If I change my API to close the session after every commit, P2 sees
the change as if commiting was not actually writing to disk and
closing the session did it. I do not understand this behavour as the
sqa documentation encourages to create a global session in a thread a
work with it (which is done with the scoped_session mechanism)
My configuration is : Linux OS, SQA 0.8.4 and a ram based db
(/dev/shm/my_db.sqlite but the problem is still there with regular
disk based db on my ~/my_db.sqlite)
Thanks a lot for your time,
Pierre
--
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.
--
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.
