4.0.0: JDBC connections sharing task-queue, leading to client-side deadlock

[mwm-twx]

Version

4.0.0

Context

Application code which worked without issue on 3.9.x leads to a (non-database) deadlock on 4.0.0.

This is the scenario:

1. Concurrent requests to the application which execute a number of database statements within transactions.
2. The first request starts a transaction and adds an entry to table1
3. Second request starts a transaction and attempts to add an entry to table1, but is due to the first requests transaction having locked the row
4. First request attempts to add a row to table2, within the same transaction.

Each database action is handled within vertx as a blocking operation (JDBCConnectionImpl.schedule), so after the add to table1 completes, the add from the second request is executed. Since the table is locked by the transaction from the first request, which still has work to do, the second add will never return. Additional debugging shows the instances of JDBCConnectionImpl are operating over the same context (an EventLoopContext), so they shared the same ordered task queue.

In 3.9.x, each JDBCConnectionImpl had it's own TaskQueue, so operations from different connections were never interleaved.

Do you have a reproducer?

It will occur every time with my application code, but I don't have a shareable minimal case.

[Gattag]

From my understanding, the usage of TaskQueue was placed behind DuplicatedContext, now when you call ContextInternal::duplicate a new DuplicatedContext is returned with its own TaskQueue for blocking tasks, but it is otherwise near identical to the parent Context. I think the problem may lie in the fact that I do not see the DuplicatedContext per connection being created anywhere, thus they all end up sharing the same TaskQueue.

[vietj]

Can you provide a reproducer ?

…

On Fri, Feb 5, 2021 at 2:34 AM Gattag ***@***.***> wrote: From my understanding, the usage of TaskQueue was placed behind DuplicatedContext, now when you call ContextInternal::duplicate a new DuplicatedContext is returned with its own TaskQueue for blocking tasks, but it is otherwise near identical to the parent Context. I think the problem may lie in the fact that I do not see the DuplicatedContext per connection being created anywhere, thus they all end up sharing the same TaskQueue. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#203 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABXDCUDEENQCGEFBQTOLKTS5NDK7ANCNFSM4WJHAMIA> .