Add new "sync once" mode for pool.connect

Fixed critical regression caused by the change in :ticket`5497` where the
connection pool "init" phase no longer occurred within mutexed isolation,
allowing other threads to proceed with the dialect uninitialized, which
could then impact the compilation of SQL statements.

This issue is essentially the same regression which was fixed many years
ago in :ticket:`2964` in dd32540dabbee0678530fb1b0868d1eb41572dca,
which was missed this time as the test suite fo
that issue only tested the pool in isolation, and assumed the
"first_connect" event would be used by the Engine.  However
:ticket:`5497` stopped using "first_connect" and no test detected
the lack of mutexing, that has been resolved here through
the addition of more tests.

This fix also identifies what is probably a bug in earlier versions
of SQLAlchemy where the "first_connect" handler would be cancelled
if the initializer failed; this is evidenced by
test_explode_in_initializer which was doing a reconnect due to
c.rollback() yet wasn't hanging.  We now solve this issue by
preventing the manufactured Connection from ever reconnecting
inside the first_connect handler.

Also remove the "_sqla_unwrap" test attribute; this is almost
not used anymore however we can use a more targeted
wrapper supplied by the testing.engines.proxying_engine
function.

See if we can also open up Oracle for "ad hoc engines" tests
now that we have better connection management logic.

Fixes: #6337
Change-Id: I4a3476625c4606f1a304dbc940d500325e8adc1a

1 files changed, 16 insertions, 1 deletions

diff --git a/test/engine/test_pool.py b/test/engine/test_pool.py
index 1c3880504..5b6dcfa45 100644
--- a/test/engine/test_pool.py
+++ b/test/engine/test_pool.py
@@ -780,7 +780,22 @@ class PoolEventsTest(PoolTestBase):
 
 
 class PoolFirstConnectSyncTest(PoolTestBase):
-    # test [ticket:2964]
+    """test for :ticket:`2964`, where the pool would not mutex the
+    initialization of the dialect.
+
+    Unfortunately, as discussed in :ticket:`6337`, this test suite did not
+    ensure that the ``Engine`` itself actually uses the "first_connect" event,
+    so when :ticket:`5497` came along, the "first_connect" event was no longer
+    used and no test detected the re-introduction of the exact same race
+    condition, which was now worse as the un-initialized dialect would now
+    pollute the SQL cache causing the application to not work at all.
+
+    A new suite has therefore been added in test/engine/test_execute.py->
+    OnConnectTest::test_initialize_connect_race to ensure that the engine
+    in total synchronizes the "first_connect" process, which now works
+    using a new events feature _exec_w_sync_on_first_run.
+
+    """
 
     @testing.requires.timing_intensive
     def test_sync(self):