heavely awkward question: you said that the error occurs in memory and
in disk. is your disk a ssd? trim enabled, noatime in fstab, deadline as
scheduler. any of these?
On 01/20/2014 03:05 PM, pr64 wrote:
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.
--
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.
