On 04/18/2017 10:19 PM, JinRong Cai wrote:
Hi:
SQLA is used in my python project. And in my code, I have the green
thread used. And the green thread was killed in some of my code. After
the the thread was killed, and the transaction was just began. And the
database connection was still in
Hi:
SQLA is used in my python project. And in my code, I have the green thread
used. And the green thread was killed in some of my code. After the the
thread was killed, and the transaction was just began. And the database
connection was still in postgresql server side with status "idle in
I'm using ZopeTransactionExtension (postgresql) as:
DBSession =
scoped_session(sessionmaker(extension=ZopeTransactionExtension()))Base =
declarative_base()
When I invoke
result = DBSession.execute(some sql query)
The result comes back fine, however I notice when I review the server status
On Saturday, February 14, 2015 at 9:58:26 PM UTC-5, Ed Rahn wrote:
This seems like a fairly common use case, do people just not care about
it or how do they handle it?
This isn't common, and looks like an anti-pattern.
Consider these lines from your emails - they're not really compatible
Ed Rahn edsr...@gmail.com wrote:
On 02/13/2015 11:30 PM, Michael Bayer wrote:
Ed Rahn edsr...@gmail.com wrote:
I have several programs that are Multi Process and long running, they open
up 30 or so connections and do selects periodically. For a select query,
the default behaviour is to
On 02/13/2015 11:30 PM, Michael Bayer wrote:
Ed Rahn edsr...@gmail.com wrote:
I have several programs that are Multi Process and long running, they open
up 30 or so connections and do selects periodically. For a select query,
the default behaviour is to begin a transaction if not currently
Ed Rahn edsr...@gmail.com wrote:
I have several programs that are Multi Process and long running, they open
up 30 or so connections and do selects periodically. For a select query,
the default behaviour is to begin a transaction if not currently in one,
but not commit afterwards. This
I have several programs that are Multi Process and long running, they
open up 30 or so connections and do selects periodically.
For a select query, the default behaviour is to begin a transaction if
not currently in one, but not commit afterwards. This leaves a large
number of postgresql
