Open StefanLiebig opened 5 years ago
I haven't been able to reproduce this error, it would be great to get to know more about your specific environment.
What do transacted
and selectTimeEntries
do?
and how big is big enough?
Oh, this is really strange.
In the meanwhile I have been updating exposed (org.jetbrains.exposed) to 0.15.1and the above transacted
has become
suspend fun <T> transacted(statement: Transaction.() -> T): T =
suspendedTransaction { // org.jetbrains.exposed.sql.transactions.experimental.suspendedTransaction(..)
statement()
}
with this it does no longer fail! With the prior version of exposed which does not have the (experimental)
suspendedTransaction
the transacted
was
suspend fun <T> transacted(statement: Transaction.() -> T): T =
withContext(Dispatchers.IO) {
transaction { // org.jetbrains.exposed.sql.transactions.transaction(..)
statement()
}
}
selectTimeEntries
just selected a bunch of time entries from the database (with exposed). A TimeEntry is a data class.
What is big enough? If the result list from the select gets greater than 30-40 it fails (hangs).
This really puzzles me. I do not see where or why this can interfere. But it seems that it does.
Any idea?
(updated kraphql to 0.6.4 - looks good)
The issue is most likely due to ThreadLocal not working predictably in coroutines. Quote from their wiki:
Exposed store some values in thread-local variables while Coroutines could (and will) be executed in different threads.
In other words, Exposed did not yet support suspended transactions.
Yes, I know. This is the problem of exposed and JDBC which rely on ThreadLocals. And the stacktrace does not look like a problem with ThreadLocal.
However, the old version of the transacted
function with the kgraphql (0.3.1) worked well. There must have been a change in kraphql that caused this effect. I do not say that this is an errror in kraphql.
Because the current versions of kotlin, ktor, exposed and kraphql work I propose to close the issue.
I would love a failing unit test before closing this issue. I will try to replicate this while being on version 0.4.0 and create a unit test there.
Yes, understand that but keep in mind that our test was just technicaly a unit test. The test for that is an integration test which started MySQL and started a ktor server and than made a graphql request to it. So graphql sits "between" ktor and exposed which calls via JDBC MySQL.
Schema.execute( .. ) will not return from suspendResolver { .. } if the result size is big "enough". This behaviour starts with switching from 0.3.1 to 0.4.0. Kgraphql runs in Ktor 1.2.1. The suspendResolver { .. } is
The result will be printed (for debugging) and but Schema.execute( .. ) will not return. When executing the test in debug mode and pausing execution the stacktrace looks like this:
If the data (result) returned from the selection is smaller the test passes. And it depends on the machine it is running on. And it also happens in production.