connection = engine.connect()
table.drop(bind=connection)
+.. index::
+ single: thread safety; connections
+
Connection facts:
-* the Connection object is **not threadsafe**. While a Connection can be shared among threads using properly synchronized access, this is also not recommended as many DBAPIs have issues with, if not outright disallow, sharing of connection state between threads.
+* the Connection object is **not thread-safe**. While a Connection can be shared among threads using properly synchronized access, this is also not recommended as many DBAPIs have issues with, if not outright disallow, sharing of connection state between threads.
* The Connection object represents a single dbapi connection checked out from the connection pool. In this state, the connection pool has no affect upon the connection, including its expiration or timeout state. For the connection pool to properly manage connections, **connections should be returned to the connection pool (i.e. ``connection.close()``) whenever the connection is not in use**. If your application has a need for management of multiple connections or is otherwise long running (this includes all web applications, threaded or not), don't hold a single connection open at the module level.
Using Transactions with Connection
Note that SQLAlchemy's Object Relational Mapper also provides a way to control transaction scope at a higher level; this is described in `unitofwork_transaction`.
+.. index::
+ single: thread safety; transactions
+
Transaction Facts:
-* the Transaction object, just like its parent Connection, is **not threadsafe**.
+* the Transaction object, just like its parent Connection, is **not thread-safe**.
* SQLAlchemy 0.4 will feature transactions with two-phase commit capability as well as SAVEPOINT capability.
Understanding Autocommit
session = Session.object_session(someobject)
-* Is the session threadsafe ?
+.. index::
+ single: thread safety; sessions
+ single: thread safety; Session
+
+* Is the session thread-safe?
Nope. It has no thread synchronization of any kind built in, and particularly when you do a flush operation, it definitely is not open to concurrent threads accessing it, because it holds onto a single database connection at that point. If you use a session which is non-transactional for read operations only, it's still not thread-"safe", but you also wont get any catastrophic failures either, since it opens and closes connections on an as-needed basis; it's just that different threads might load the same objects independently of each other, but only one will wind up in the identity map (however, the other one might still live in a collection somewhere).
as ClauseElement, Compiled and DefaultGenerator objects. Provides
a begin method to return Transaction objects.
- The Connection object is **not** threadsafe.
-
+ The Connection object is **not** thread-safe.
+
+ .. index::
+ single: thread safety; Connection
+
"""
def __init__(self, engine, connection=None, close_with_result=False,
"""Represent a Transaction in progress.
The Transaction object is **not** threadsafe.
+
+ .. index::
+ single: thread safety; Transaction
+
"""
def __init__(self, connection, parent):
Direct usage of ``SessionTransaction`` is not necessary as of SQLAlchemy
0.4; use the ``begin()`` and ``commit()`` methods on ``Session`` itself.
- The ``SessionTransaction`` object is **not** threadsafe.
+ The ``SessionTransaction`` object is **not** thread-safe.
+
+ .. index::
+ single: thread safety; SessionTransaction
"""
"""A collection of Tables and their associated schema constructs.
Holds a collection of Tables and an optional binding to an ``Engine`` or
- ``Connection``. If bound, the :class:`~sqlalchemy.schema.Table` objects in the
- collection and their columns may participate in implicit SQL execution.
+ ``Connection``. If bound, the :class:`~sqlalchemy.schema.Table` objects
+ in the collection and their columns may participate in implicit SQL
+ execution.
- The `Table` objects themselves are stored in the `metadata.tables`
+ The `Table` objects themselves are stored in the `metadata.tables`
dictionary.
-
+
The ``bind`` property may be assigned to dynamically. A common pattern is
to start unbound and then bind later when an engine is available::
MetaData is a thread-safe object after tables have been explicitly defined
or loaded via reflection.
+
+ .. index::
+ single: thread safety; MetaData
+
"""
__visit_name__ = 'metadata'