I've used timing around the events to determine long statement execution
and transaction times. A trick I learned was logging that stuff to a
separate database 'autocommit' enabled database and session.
• If a statement took took long to execute, I'd log the query + params.
• If the session to
On 4/1/15 12:08 PM, Eric Smith wrote:
> Thanks Michael -- I appreciate how responsive you are to questions.
>
> Yes, it would have been more precise to talk about pysqlite's locking
> model rather than SQLite's. I'm hesitant to increase the lock timeout
> because I don't think I want any transact
Thanks Michael -- I appreciate how responsive you are to questions.
Yes, it would have been more precise to talk about pysqlite's locking model
rather than SQLite's. I'm hesitant to increase the lock timeout because I
don't think I want any transactions that are that long, and would rather
root
On 3/31/15 7:23 PM, Eric Smith wrote:
> Environment: SQLAlchemy 0.9.7, SQLite back-end, autoflush=True, mostly
> using scoped session, multi-platform Python 2.7
>
> I'm working on a multi-threaded app, but with fairly low concurrency
> (user actions and scheduled tasks are on different threads, f
Environment: SQLAlchemy 0.9.7, SQLite back-end, autoflush=True, mostly
using scoped session, multi-platform Python 2.7
I'm working on a multi-threaded app, but with fairly low concurrency (user
actions and scheduled tasks are on different threads, for example). I think
I have a fair understandi
