On Thu, May 14, 2020, at 8:35 AM, Kent Bower wrote:
> Returned to pool in rolled back state now, thanks.
>
> However, the script I sent in this post now hits the "SAWarning: Reset agent
> is not active. This should not occur unless there was already a connectivity
> error in progress." on the
Returned to pool in rolled back state now, thanks.
However, the script I sent in this post now hits the "SAWarning: Reset
agent is not active. This should not occur unless there was already a
connectivity error in progress." on the conn.close() call.
Did you expect that because my usage pattern
this is getting released today in any case so, just look for any more warnings
or conditions like this. the most important part is getting the test coverage
in so as I refactor for 1.4 / 2.0 the behavioral contract is maintained. thanks!
On Wed, May 13, 2020, at 1:16 PM, Kent Bower wrote:
>
Very good, will do when I find time.
Thank you!
On Wed, May 13, 2020 at 1:07 PM Mike Bayer wrote:
> feel free to test the patch at:
>
> https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/1965
>
> this patch includes that if the transaction state at the engine level gets
> screwed up, the
feel free to test the patch at:
https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/1965
this patch includes that if the transaction state at the engine level gets
screwed up, the pool will warn and still make sure it does a real rollback. you
should not see this warning however.
in 2.0,
LOL, you're welcome, I'm such a great tester, aren't I?
Anyway, everything after 0.9.2 behaved this way. 0.9.1 did a rollback.
On Wed, May 13, 2020 at 11:54 AM Mike Bayer
wrote:
> nevermind, you've managed to find a case that trips it up for the
> connection pool
>
> release today
>
>
>
> On
nevermind, you've managed to find a case that trips it up for the connection
pool
release today
On Wed, May 13, 2020, at 11:51 AM, Mike Bayer wrote:
>
>
> On Wed, May 13, 2020, at 11:39 AM, Kent Bower wrote:
>> In this script, conn.close() does *not *call rollback on the transaction. It
>>
On Wed, May 13, 2020, at 11:39 AM, Kent Bower wrote:
> In this script, conn.close() does *not *call rollback on the transaction. It
> isn't just a logging issue as I've verified from the database that the
> session was not rolled back.
I can confirm that in master only where things have
In this script, conn.close() does *not *call rollback on the transaction.
It isn't just a logging issue as I've verified from the database that the
session was not rolled back.
On Wed, May 13, 2020 at 11:31 AM Mike Bayer
wrote:
> Haven't looked deeply but so far what you need to know is that
>
Haven't looked deeply but so far what you need to know is that conn.close()
*ALWAYS* rolls back the transaction, just not at the Engine level, it's at the
connection pool level so you won't see it when logging / event hooking on the
Engine. turn on echo_pool and you will see this, in modern
Mike, et al.,
I've got some questions about closing connections. I suspect my framework
may be at fault, but there is potentially a sqlalchemy issue here as well.
See attached script with nested transaction and explicit connection.close().
Things are even more complex because versions have
11 matches
Mail list logo
