Getting some weird behavior here. I've recently in...

# exposed

[robin]

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?

Untitled

[robin]

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?

[tapac]

Do you use coroutines in your code?

[robin]

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?

[tapac]

Do you use other suspend functions inside transaction block?

[robin]

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?

[tapac]

Try to replace transaction with suspendedTransaction or newSuspendedTransaction

[robin]

I will try that, thanks!

[robin]

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.

[robin]

If you like, I can create an issue about that were we can discuss the details.