Hello, are there any plans to deprecate and remove...

# exposed

[Antanas A.]

Hello, are there any plans to deprecate and remove singletons/statics from a library? Now it's complicated to use it in asynchronous environment (coroutines, multi-thread), and not sure if it's compatible with ktor

[tapac]

https://github.com/JetBrains/Exposed/issues/255

[Antanas A.]

understood, by looking and Exposed code it seems non trivial to implement explicit transaction manager because of singletons all over place

[Antanas A.]

doing some prototyping on removing singletons

[tapac]

It's not necessary to remove "Singletons" as we just have to provide thread locals into coroutine scopes but it's not obvious how to keep current behavior and provided support for suspend

[Antanas A.]

I think it would be better to remove all singletons and all variables which is implicitly used as global variables

[Antanas A.]

because of coroutines and multi threaded environment

[Antanas A.]

avoiding any glitches on race conditions and reentrant invocations

[Antanas A.]

now I can seen that ThreadManager.manager global is temporary set and restored using resetCurrent()

[Antanas A.]

and cannot image what would happen if production system uses this with coroutines which can simultaneously run many coroutines on the same thread

[tapac]

Yes, but every thread has it's own "current" copy of manager,

[Antanas A.]

with thread it's ok

[Antanas A.]

with coroutines which has a thread pool it's not

[Antanas A.]

but, hm. maybe ok

[Antanas A.]

if everything is blocking (synchronous)

[tapac]

There is https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/java.lang.-thread-local/as-context-element.html
which was designed to bridge thread local and coroutines.

[Antanas A.]

currently we are trying to manage transactions to work correctly

[Antanas A.]

now if execution is spawned to another thread during context switch

[tapac]

Did you look at this comment https://github.com/JetBrains/Exposed/issues/255#issuecomment-450395069 ?

[Antanas A.]

it gets duplicated and rollback not works properly

[Antanas A.]

is this will stick current transaction manager and carry all down in a suspend function calls?

[tapac]

AFAIU within launch block manager should be the same as before entering that block on any Dispatchers.Default thread. But you have to provide currentTransactionContext into every scope where you expect to execute Exposed methods.

[tapac]

Like:

launch(Dispatchers.Default + currentTransactionContext()) {
   ...
    runBlocking(<http://Dispatchers.IO|Dispatchers.IO> + currentTransactionContext()) { 
       ....
    }
}

[Antanas A.]

got it, thanks.

[Antanas A.]

is there a reason why transaction manager is different per each thread?

[Antanas A.]

little bit restructuring: https://github.com/antanas-arvasevicius/Exposed/commit/b98b27130441219ff8e71f643ff148d388350f0a?diff=unified

[tapac]

is there a reason why transaction manager is different per each thread?

You might want to work with different Databases in separate threads

[Antanas A.]

that make sense

[Antanas A.]

but TransactionManager.current(database:Database) also could be used

[Antanas A.]

or it was designed to not explicitly pass database object everythere?

[tapac]

Yes, to reduce boilerplate. Possibly it was a huge design f*ckup (it was designed that way by initial creator of Exposed).

[Antanas A.]

It feels like that 🙂

[Antanas A.]

because of kotlin DSL support it could be just made more cleaner all functions just could be added as extension functions on Transaction maybe

[Antanas A.]

seems like library was written for java

[Antanas A.]

but I really like query builder

[Antanas A.]

and overall API

[tapac]

The problem here in DAO objects as they can't be "scoped" as extension functions.