Page MenuHomePhabricator

When a GlobalLock with an external connection is released, don't return it to the pool
ClosedPublic

Authored by epriestley on Mar 2 2021, 8:49 PM.
Tags
None
Referenced Files
F18160499: D21583.id51388.diff
Fri, Aug 15, 2:02 AM
F18142474: D21583.id51380.diff
Thu, Aug 14, 12:24 PM
F18112372: D21583.diff
Tue, Aug 12, 4:30 PM
F18033542: D21583.id.diff
Sun, Aug 3, 12:48 AM
F17974630: D21583.diff
Fri, Aug 1, 4:47 PM
F17954256: D21583.id51380.diff
Fri, Aug 1, 3:56 AM
F17940331: D21583.id51388.diff
Thu, Jul 31, 4:15 AM
F17807181: D21583.id51380.diff
Jul 25 2025, 2:39 PM
Subscribers
None

Details

Summary

Ref T13627. Currently, global locks always return connections (even external connections) to the connection pool when unlocked.

This code is obviously buggy: isExternalConnection is set to false immediately before it is tested. This bug has existed since this code was introduced, in D15792.

  • Instead of storing a flag, store the actual connection.
  • Don't clear it when unlocking.
  • Don't return external connections to the pool.
Test Plan
  • Added a failing test, made it pass.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable