Thanks for the quick reply! On Wednesday, February 21, 2018 at 6:44:33 PM UTC+1, Mike Bayer wrote: > > I can come up with other things that can break based on the idea that > you're doing a full connection + execute sequence within the log > handler deep within that engine's own processes, such as, it can cause > connection pool exhaustion when you're working with the last > connection available, then your logger has no connection, it goes to > get one and...hang. I can reproduce this with your script (set > pool_size=1, max_overflow=0, set up logging and run an execute() so it > actually logs, and it hangs for 30 seconds until the timeout and > crashes, see stack trace below), so your approach is not safe in any > case. >
Thanks for the clarification. > It would be a lot simpler and robust if your log handler just used its > own Engine (make a new one from the engine.url you already have). Good idea. > That way you can lose all that re-entrant mutex stuff too. > The mutex stuff is there because in the actual code SQLAlchemy logging is switched on and I want to prevent that SQLAlchemy tries to log the insert statement in `_emit`. I didn't think of this when I posted the original question, so I could have left out the mutex stuff for the sake of the example code. Best regards, Stefan -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
