Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Dennis Lee Bieber <wlfraed@ix.netcom.com>
Subject: Re: Problems with ZODB, I can not persist and object accessed from 2 threads
Date: Tue, 06 May 2014 20:00:47 -0400
Organization: IISS Elusive Unicorn
References: <CAMxmM6boETC3DoB+1-Eeg+6O8ebcrwt1Mz4fYbrua_3kSYttVg@mail.gmail.com> <87iopjyxsj.fsf@handshake.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.9716.1399420861.18130.python-list@python.org>
Lines: 85
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:70993

On Tue, 06 May 2014 13:03:08 +0200, dieter <dieter@handshake.de> declaimed
the following:

>
>The database (we have called it "db") is global to all threads.
>Each thread must open (and maybe close) its own connection to the
>global database. You must never share the same connection or
>objects loaded via the connection between threads - very weird
>(and apparently non-deterministic) errors can result.
>
	Actually, one should study the documentation for the dbapi adapter
being used -- some may allow the connection (db = adapter.connect(...)) to
be shared by threads, but require each thread to create its own cursor (cur
= db.cursor())

	Some may even allow cursors to be shared <shudder>


	db-api defines a constant to tell one what is permitted.

http://mysql-python.sourceforge.net/MySQLdb.html
"""
threadsafety

    Integer constant stating the level of thread safety the interface
supports. This is set to 1, which means: Threads may share the module.

    The MySQL protocol can not handle multiple threads using the same
connection at once. Some earlier versions of MySQLdb utilized locking to
achieve a threadsafety of 2. While this is not terribly hard to accomplish
using the standard Cursor class (which uses mysql_store_result()), it is
complicated by SSCursor (which uses mysql_use_result(); with the latter you
must ensure all the rows have been read before another query can be
executed. It is further complicated by the addition of transactions, since
transactions start when a cursor execute a query, but end when COMMIT or
ROLLBACK is executed by the Connection object. Two threads simply cannot
share a connection while a transaction is in progress, in addition to not
being able to share it during query execution. This excessively complicated
the code to the point where it just isn't worth it.
"""

https://pysqlite.readthedocs.org/en/latest/sqlite3.html#multithreading
"""
Older SQLite versions had issues with sharing connections between threads.
That’s why the Python module disallows sharing connections and cursors
between threads. If you still try to do so, you will get an exception at
runtime.

The only exception is calling the interrupt() method, which only makes
sense to call from a different thread.
"""

http://initd.org/psycopg/docs/usage.html#thread-and-process-safety
"""
The Psycopg module and the connection objects are thread-safe: many threads
can access the same database either using separate sessions and creating a
connection per thread or using the same connection and creating separate
cursors. In DB API 2.0 parlance, Psycopg is level 2 thread safe.

The difference between the above two approaches is that, using different
connections, the commands will be executed in different sessions and will
be served by different server processes. On the other hand, using many
cursors on the same connection, all the commands will be executed in the
same session (and in the same transaction if the connection is not in
autocommit mode), but they will be serialized.
"""

http://www.firebirdtest.com/file/documentation/drivers_documentation/python/3.3.0/thread-safety-overview.html#definition-of-thread-safety
"""
Currently, the highest level of concurrency supported by any version of the
Firebird client library is thread-safety at the connection level.

When we say that the Firebird client library is thread-safe at the
connection level, we mean that it is safe to use a particular connection in
only one thread at a time, although the same connection can be manipulated
by different threads in a serial fashion, and different connections can be
manipulated by different threads in parallel.
"""



-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/