Inside a Ktor post { … } I have the following code:

val dao = newSuspendedTransaction { MyDAO.findByValueOrThrowException(value) }

// MyDAO companion (LongEntityClass)
 suspend fun findByValueOrThrowException(value: String): MyDAO {
        return withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
                find { MyTable.value eq value }.firstOrNull() ?: throw RuntimeException("MyDAO not found")
      }
}

10 seconds after the exception is thrown, I get the following log message: com.zaxxer.hikari.pool.ProxyLeakTask - Connection leak detection triggered for org.postgresql.jdbc.PgConnection@5b4d25e7 on thread DefaultDispatcher-worker-1, stack trace follows: java.lang.Exception: Apparent connection leak detected As you can see, I am using Hikari for a thread pool (config.leakDetectionThreshold = 10000L, corresponding to the 10 seconds after the message appears) So am I not allowed to throw an exception and catch it outside the transaction context, or am I doing something else wrong? (I am using Postgres)

I havent used

newSuspendedTransaction

yet but why do you change context ?

You can also provide the context directly with newSuspendedTransaction(Dispatchers.IO) { … }, I did it this way to ensure that when my suspend fun is called, it is always called in the IO Dispatcher and not accidentally on another one.

What makes you think its not safe to do in any dispatcher ?

I’m not sure, as you can see in the example above from Evan R., they also specify the Dispatcher explicitly. But I wouldn’t think that this would be the problem.

@spand exposed coroutine support is currently experimental according to the docs, but newSuspendedTransaction will always start a transaction in the current coroutine context unless a different one is specified explicitly

I am sorry if I am just making noise here but I would expect this to work:

val myDAO = newSuspendedTransaction { find { MyTable.value eq value }.firstOrNull() } ?: throw RuntimeException()

It does work, but the calls inside newSuspendedTransaction will block threads of the current coroutine context you’re running in if you don’t specify the dispatcher. Better to explicitly specify to run in the IO dispatcher to avoid blocking the default dispatcher’s thread pool

Where is the blocking call here? https://github.com/JetBrains/Exposed/blob/52bc6f8fd50b958beb5b3c3054d7745a8b3cff18/exposed-core/src/main/kotlin/org/jetbrains/exposed/sql/transactions/experimental/Suspended.kt

tx.statement() in TransactionScope.suspendedTransactionAsyncInternal As stated at https://github.com/JetBrains/Exposed/wiki/Transactions: “Please note [that transactions invoked inside newSuspendedTransaction] remains blocking (as it still uses JDBC)”