Avoid creating asyncio.Lock on the wrong loop.

Fixed a regression introduced by :ticket:`6337` that would create an
``asyncio.Lock`` which could be attached to the wrong loop when
instantiating the async engine before any asyncio loop was started, leading
to an asyncio error message when attempting to use the engine under certain
circumstances.

Fixes: #6409
Change-Id: I8119c56b44a7bd70a650c0ea676892d4d7814a8b

1 files changed, 8 insertions, 2 deletions

diff --git a/lib/sqlalchemy/util/_concurrency_py3k.py b/lib/sqlalchemy/util/_concurrency_py3k.py
index b905f903b..5f03972b2 100644
--- a/lib/sqlalchemy/util/_concurrency_py3k.py
+++ b/lib/sqlalchemy/util/_concurrency_py3k.py
@@ -7,6 +7,7 @@ from typing import Coroutine
 import greenlet
 
 from . import compat
+from .langhelpers import memoized_property
 from .. import exc
 
 
@@ -132,10 +133,15 @@ async def greenlet_spawn(
 
 
 class AsyncAdaptedLock:
-    def __init__(self):
-        self.mutex = asyncio.Lock()
+    @memoized_property
+    def mutex(self):
+        # there should not be a race here for coroutines creating the
+        # new lock as we are not using await, so therefore no concurrency
+        return asyncio.Lock()
 
     def __enter__(self):
+        # await is used to acquire the lock only after the first calling
+        # coroutine has created the mutex.
         await_fallback(self.mutex.acquire())
         return self