Objectify and threads, especially Kotlin coroutines

[frederik...@gmail.com]

Hey,

a growing number of Kotlin projects is using kotlinx.coroutines. That means multiple async operations are spread over a number of threads. Ktor webserver uses coroutines as well as kotest testing-library. These don't work well with Objectify as the thread of the async operation can change during it, in ktor for the http request, in kotest for the testing operation. The threadlocal Objectify instance approach does not work well with it.

I wonder why this design decision was made for Objectify as the underlying datastore object is described to be thread-safe. Is it possible to use one global Objectify instance?

Thanks!

Best Frederik

[Jeff Schnitzer]

Strange, this one went to my spam folder. Sorry about the late response.

The idea of a thread local session (transaction context, entity cache) is pretty standard fare for persistence frameworks. It's very convenient for business logic in the traditional app engine model. You're right, it isn't very convenient in heavy async frameworks. However, it will work very well with Project Loom.

IMO, Kotlin went down the wrong path and Java's going down the right path (about this - there's generally a lot to like about Kotlin). 

I don't know how to help here. Sorry.

Jeff

--
You received this message because you are subscribed to the Google Groups "objectify-appengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to objectify-appen...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/objectify-appengine/6b77fd88-d52b-4351-b961-b80316ddb63an%40googlegroups.com.

[frederik...@gmail.com]

Thanks for the good explanation. I guess I should use the low-level datastore library then for ktor. Maybe it's interesting to ask jetbrains/kotlin about their idea of persisting when the threadlocal approach is "standard".