Hi Michael,

On 11/09/2012 11:36 PM, Michael Bayer wrote:
> On Nov 8, 2012, at 5:01 PM, Torsten Landschoff wrote:
>> My first tests with the SQLAlchemy core where promising, but when using
>> the ORM I get a bunch of deadlocks where it seems like the session opens
>> two connections A and B where A locks B out.
> The Session never does this, assuming just one Engine associated with it.  It 
> acquires one Connection from the Engine, holds onto it and uses just that 
> connection, until commit() at which point the connection is released to the 
> pool.   
Okay, thanks, maybe the error was elsewhere then.
> SQLite supports a "SERIALIZABLE" mode of isolation, in conjunction with a 
> workaround for a pysqlite bug 
> (http://docs.sqlalchemy.org/en/rel_0_7/dialects/sqlite.html#serializable-transaction-isolation)
>  which might be what you're looking for, though I generally try to steer 
> users away from any usage of SQLite that depends on high concurrency (see 
> "High Concurrency" at http://sqlite.org/whentouse.html).
I do not consider an application that downloads new records once per
hour concurrently to the GUI "high concurrency". And that background
process is not really a problem either, as long as I just lock the
database all the time. This makes the gui freeze for a couple of minutes
though.
Therefore I am looking for a solution that will make background and main
thread cooperate wrt. database access.

BTW: The main issue is not concurrency in itself. SQLite just uses
filesystem locking which are basically spin locks. So as long as the
background thread updates the database it has a high probability to
reacquire the lock after each transaction while the GUI thread will fail
to hit the slots where the db is not locked.

> To diagnose this code, you'd need to make use of the tools available - which 
> includes connection pool logging, engine logging, and possibly usage of 
> custom pools like sqlalchemy.pool.AssertionPool which ensures that only one 
> connection is used at any time.
Thanks for the pointer to AssertionPool. I already use the others.

BTW, I found one offender that breaks running database upgrades with my
locking schemes:

from sqlalchemy import *
from sqlalchemy.pool import *

engine = create_engine("sqlite:////home/torsten/some.db",
poolclass=AssertionPool)
conn = engine.connect()
metadata = MetaData(conn, reflect=True)

This results in the following backtrace here:

$ python demo.py
Traceback (most recent call last):
  File "demo.py", line 6, in <module>
    metadata = MetaData(conn, reflect=True)
  File
"/opt/dynasdk/loco2-precise/lib/python2.7/site-packages/sqlalchemy/schema.py",
line 2363, in __init__
    self.reflect()
  File
"/opt/dynasdk/loco2-precise/lib/python2.7/site-packages/sqlalchemy/schema.py",
line 2497, in reflect
    connection=conn))
  File
"/opt/dynasdk/loco2-precise/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
line 2504, in table_names
    conn = self.contextual_connect()
  File
"/opt/dynasdk/loco2-precise/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
line 2490, in contextual_connect
    self.pool.connect(),
  File
"/opt/dynasdk/loco2-precise/lib/python2.7/site-packages/sqlalchemy/pool.py",
line 224, in connect
    return _ConnectionFairy(self).checkout()
  File
"/opt/dynasdk/loco2-precise/lib/python2.7/site-packages/sqlalchemy/pool.py",
line 387, in __init__
    rec = self._connection_record = pool._do_get()
  File
"/opt/dynasdk/loco2-precise/lib/python2.7/site-packages/sqlalchemy/pool.py",
line 911, in _do_get
    raise AssertionError("connection is already checked out" + suffix)
AssertionError: connection is already checked out at:
  File "demo.py", line 5, in <module>
    conn = engine.connect()

I would have expected it to reflect using the connection passed to the
MetaData constructor.

Greetings, Torsten

-- 
DYNAmore Gesellschaft fuer Ingenieurdienstleistungen mbH
Torsten Landschoff

Office Dresden
Tel: +49-(0)351-4519587
Fax: +49-(0)351-4519561

mailto:[email protected]
http://www.dynamore.de

Registration court: Mannheim, HRB: 109659, based in Karlsruhe,
Managing director:  Prof. Dr. K. Schweizerhof, Dipl.-Math. U. Franz

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to