Michael Bayer wrote:
Michael Bayer wrote:
it is quite simple to implement yourself, use a ConnectionProxy.
Ah, ok, didn't know about them :-)
Out of interest, is echo=True implemented as a ConnectionProxy?
its not. CP is a little heavyhanded for just the built-in SQL logging.
How/where
On Jan 17, 2010, at 12:54 PM, Chris Withers wrote:
Michael Bayer wrote:
Michael Bayer wrote:
it is quite simple to implement yourself, use a ConnectionProxy.
Ah, ok, didn't know about them :-)
Out of interest, is echo=True implemented as a ConnectionProxy?
its not. CP is a little
On Jan 16, 2010, at 6:18 AM, Chris Withers wrote:
Michael Bayer wrote:
[1] I'm not sure you could actually use exc_info=True, since no
exception will have been raised at this point, you just need a repr of
the current strack trace.
when is a stack trace emitted ?
Well, 'would be', not
Michael Bayer wrote:
it is quite simple to implement yourself, use a ConnectionProxy.
Ah, ok, didn't know about them :-)
Out of interest, is echo=True implemented as a ConnectionProxy?
Its like a ten liner. Here's an example: http://techspot.zzzeek.org/?p=31
Thanks.
however
On Jan 16, 2010, at 1:09 PM, Chris Withers wrote:
Michael Bayer wrote:
it is quite simple to implement yourself, use a ConnectionProxy.
Ah, ok, didn't know about them :-)
Out of interest, is echo=True implemented as a ConnectionProxy?
its not. CP is a little heavyhanded for just the
Michael Bayer wrote:
Chris Withers wrote:
Easiest way to trap it is to monkeypatch Session.rollback(), or whatever
rollback you think you might be calling, with a def that calls
pdb.set_trace() or dumps a stack trace using inspect().
Any chance of SA growing the ability to do the latter
Chris Withers wrote:
Michael Bayer wrote:
Chris Withers wrote:
Easiest way to trap it is to monkeypatch Session.rollback(), or
whatever
rollback you think you might be calling, with a def that calls
pdb.set_trace() or dumps a stack trace using inspect().
Any chance of SA growing the ability
Michael Bayer wrote:
the connection pool issues a ROLLBACK when a connection is returned to the pool. This releases any remaining transactional state on the connection.
Ah, that'd probably do it.
However, this particular ROLLBACK isn't logged with the echo=True part of
things, so you'd
Chris Withers wrote:
Easiest way to trap it is to monkeypatch Session.rollback(), or whatever
rollback you think you might be calling, with a def that calls
pdb.set_trace() or dumps a stack trace using inspect().
Any chance of SA growing the ability to do the latter itself?
Again, I really
Hi All,
So, we have some (well, about 1.7M a day, so more than some...) unknown
ROLLBACKs occurring. Creating the engine with echo=True can show use
that these rollbacks are indeed happening, but tracking these down lead
me to a more widespread question:
If you have analysis tools that tell
the connection pool issues a ROLLBACK when a connection is returned to the
pool. This releases any remaining transactional state on the connection.
However, this particular ROLLBACK isn't logged with the echo=True part of
things, so you'd only see this in your MySQL logs - the echo setting
11 matches
Mail list logo
