A modern programming language that makes developers happier.

kotlinlang

1. I am experiencing "No transaction in context"  intermittently from when I updated to the latest 1.0.0-RC. With previous version I have never seen this problem unless it was true I had forgotten to put the transaction there.  
2.  Previously I was passing <http://Dispatchers.IO|Dispatchers.IO> to suspendTransaction to avoid a previous problem of context switching when making SELECTS with R2DBC. Now I need to surround the suspendTransaction with "withContext(<http://Dispatchers.IO|Dispatchers.IO>)" to avoid the same problem, because you are deprecating this overload....

Hi,  that's a kind of old problem: <https://kotlinlang.slack.com/archives/C0CG7E0A1/p1759953346920929?thread_ts=1754576366.032609&amp;cid=C0CG7E0A1>

I ran into same problem for 2 days. I use Kotlin with _SpringBoot (3.5.6 latest)_ and Graphql, Exposed 1.0.0-RC, r2dbc. Graphql controllers are `suspended` since SpringBoot-webflux now supports suspended call chain.

So, the workaround is passing <http://Dispatcher.IO|Dispatcher.IO> all the time?

<@U051XL4V3SR> Yes, for the query side you have to do it. In previous versions i was injecting it in the suspendTransaction, but with new design you have to sorround with "withContext"

<https://github.com/JetBrains/Exposed/blob/main/CHANGELOG.md#100-rc-2>
&gt;  fix: Refactoring of switching between coroutines by @obabichevjb in <https://github.com/JetBrains/Exposed/pull/2619|#2619>
Could this be related?

<@U05D2172ECT> <@U051XL4V3SR> I went through the problem, and if it was tested on the `1.0.0-rc-1` I'd be glad if you check it on the `1.0.0-rc-2` that was released yesterday.

With this release we refactored transaction management for r2dbc. The main goal of refactoring is eliminating thread local data as much as possible (ideally keep only thread local transactions stack), what should make the whole structure simpler and more reliable.

Right now I'm working on making the same refactoring. I created the issue to collect there all the problem I want to solve with the current refactoring <https://youtrack.jetbrains.com/projects/EXPOSED/issues/EXPOSED-897/Restructure-transaction-management|EXPOSED-897 Restructure transaction management>

Feel free to add comments here or there if you see that I missed something.

&gt; Could this be related?
<@U051XL4V3SR> yes, that was a first part of refactoring transactions management. Changes were made only to r2dbc module and should fix many `No transaction in context` issues

Great news! I will provide any info if I stumble upon anything, thanks for fixing it.
Also forgive my ignorance, since the `call context` is coroutines, why still use ThreadLocals in the solution?

The main reason to use thread locals - is the necessity to have access to the current transaction from the core module in non-suspend functions.

We need kinda global variable that would store the current transaction, but it has to be thread local, because different threads could run different transactions in parallel.

It allows to call `transaction()`/`suspendTransaction()` without arguments for example. To get access to metadata and current dialect.

Internally we often check which database and version of database we use to generate correct sql or use specific db features, and we use access to the current transaction to get information about its db.