https://kotlinlang.org logo
#exposed
Title
# exposed
r

robin

02/24/2020, 3:38 PM
Getting some weird behavior here. I've recently introduced HikariCP as a new DataSource to make use of connection pooling. The service was running smoothly for a few days, then suddenly, any call sprayed the exception in the attached snippet all over the place. Restarting the service immediately started to do the same, only rolling it back to an earlier version without HikariCP fixed the issue. Any idea where to start looking?
My biggest confusion comes from the error message itself - shouldn't Hikari automatically restart closed connections, and only hand out open connections? This seems to me like some connection is kept cached somewhere and reused beyond its lifetime. But then, why would the error appear again immediately after restarting the service, with (presumably) all-new connections?
t

tapac

02/24/2020, 5:01 PM
Do you use coroutines in your code?
r

robin

02/24/2020, 8:27 PM
Yes, we do. We're running a Ktor Server with Exposed as the Backend. But we're using only the blocking
transaction
-functions, not the suspend or async ones, and not switching Threads or dispatchers from inside a transaction, as far as I can tell, so the code inside of transactions should run fully blocking, right?
t

tapac

02/24/2020, 8:40 PM
Do you use other suspend functions inside transaction block?
r

robin

02/25/2020, 7:18 AM
Not that I know of, but can't be completely sure right now. What would we need to do to make it work, if we did?
t

tapac

02/25/2020, 8:27 AM
Try to replace
transaction
with
suspendedTransaction
or
newSuspendedTransaction
r

robin

02/25/2020, 10:00 AM
I will try that, thanks!
Looking good so far. One thing tripped us up on the way, though: simply replacing all calls to
transaction
with
newSuspendedTransaction
was not enough, as the latter doesn't automatically check if there's a transaction already in scope which to attach to, and always creates a completely new transaction instead, leading to outer transactions not being able to see changes made by inner transactions. We solved that by implementing our own
transaction
function that checks for an already open transaction in the coroutine context, and delegates to
suspendedTransaction
or
newSuspendedTransaction
accordingly. I was surprised that exposed doesn't seem to have that functionality - is this a conscious omission, or something you would welcome a pull request for? Our implementation isn't that elaborate, it wouldn't be much work to integrate it into exposed itself, so that we can have a true suspending pendant to
transaction
.
If you like, I can create an issue about that were we can discuss the details.
3 Views