Fix: eliminate remaining race conditions from SQLAlchemy Channel

Although a race condition in the SQLAlchmey Channel class was fixed in
a recent commit [0], a few other methods are also susceptible to race
conditions.

Indeed, if multiple threads call the class' `_open` method, a conflict
can occur with the `metadata.create_all` call which creates the schema
in the database, resulting in an exception which can look like this:

```
sqlalchemy.exc.IntegrityError: (psycopg2.errors.UniqueViolation)
duplicate key value violates unique constraint
"pg_type_typname_nsp_index" DETAIL: Key (typname,
typnamespace)=(queue_id_sequence, 2200) already exists.
```

Similarly, `_get_or_create` is susceptible to a race condition if two
threads try to create the unique queue object in the database at the
same time, resulting in this kind of exception:

```
sqlalchemy.exc.IntegrityError: (psycopg2.errors.UniqueViolation)
duplicate key value violates unique constraint "kombu_queue_name_key"
DETAIL: Key (name)=(celery) already exists.

[SQL: INSERT INTO kombu_queue (id, name) VALUES
(nextval('queue_id_sequence'), %(name)s) RETURNING kombu_queue.id]
[parameters: {'name': 'celery'}]
```

By using the mutex, we can ensure that only one thread at a time
executes these critical sections, eliminating the race conditions.

The mutex has been made re-entrant since `_open` can be called from
`_get_or_create`, which would cause a deadlock if a simple `Lock` was
used instead of `RLock`.

[0] 8f1de37a08318d388a048341ddca12af30019bf3

Signed-off-by: Antoine Busque <antoinebusque@gmail.com>

0 files changed, 0 insertions, 0 deletions