-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
simplify pool recycle logic #2985
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Michael Bayer (@zzzeek) wrote: test case. In this test, the current method calls engine.dispose() about seven times and seven pools are created. using the new system, only one pool is created.
|
Michael Bayer (@zzzeek) wrote:
→ eed9cfc |
Changes by Michael Bayer (@zzzeek):
|
Michael Bayer (@zzzeek) wrote:
→ 8e10ab9 |
Michael Bayer (@zzzeek) wrote:
Checks are now added within any section that
→ 85d1899 |
Migrated issue, originally created by Michael Bayer (@zzzeek)
using a simple invalidation time we can do away with all the "pool replacement" logic. the current logic is subject to a pretty obvious race condition, where as many connections all hit a disconnect wall, all of the Connection objects hosting them will simultaneously call upon self.engine.dispose(). this means we could have N pools generated and immediately chucked within a disconnect cycle.
the patch below removes all of that and replaces with a simple timeout which incurs no overhead and no race conditions. the only difference is that the "bad" connections hang around until they are invalidated on checkout.
The text was updated successfully, but these errors were encountered: