Hello Lukas, thank you for the additional information. There is some misunderstanding about the tenant-specific data. I will explain further...
My requirement would be: - Each REST-Endpoint would need to be able to set a Policy/ExecuteListener that is specific to the Authentication/Authorization Credentials (Permissions) of the Bearer in this request. As the Policy/ExecuteListener must be set on the Jooq-Configuration, i really must create the DSLContext for each REST-Request uniquely and can not share it globally. For example: Peter authenticates himself with the Backend and gets a Cookie that contains the Roles/Tenant that he is allowed to access. Peter now sends this Cookie in all REST-Requests to the Backend and the Credentials within the Cookie will be passed into the REST-Endpoint of the Framework (Spring, Quarkus,...). So i really have the need to create a Request-Specific Jooq-Configuration when i want to make use of Jooqs Policy/ExecutionListener here? In that regards the only way i would profit from Caching of the DSLContext would be within a REST-Request Scope. So if from Jooqs Side there is nothing really problematic (only slower runtimes because of not caching stuff), i would like to stick with recreating the DSLContext for each REST-Request. [email protected] schrieb am Mittwoch, 27. März 2024 um 09:26:20 UTC: > The DefaultConfiguration::data map is a ConcurrentHashMap, so readers and > writers won't corrupt the Map when accessing it concurrently. But indeed, > the Map is shared if you share the Configuration. You can either use > tenant-specific Map keys (like "com.example.tenant-1", etc.) or maintain a > Configuration per tenant, or use a "lower level" scoped map, see below. I > don't know what makes most sense to you. > > On Wed, Mar 27, 2024 at 12:39 AM 'Bernd Huber' via jOOQ User Group < > [email protected]> wrote: > >> - if thread A changed configuration.data(), will thread B also see this >> changed configuration.data() in a multi-threading environment? >> > > Yes > > If yes, then: >> - a) maybe the "data()" function for Scope-specific data may not be the >> right way to do what i need (passing around thread-specific context-objects >> in a multi-threaded environment) >> > > Each Scope has its own map, though. You don't have to register stuff to > the "top level" scope. You could implement a TransactionListener and > populate the TransactionContext.data() map instead of > TransactionContext.configuration().data(). The same is true with an > ExecuteListener, which can populate an ExecuteContext.data() map > > >> - b) i need to keep Constructing new DSLContext for every Thread to keep >> them separated, so i can use "data()" in an isolated manner. >> > > The main drawback (currently) of this is that reflection caches won't be > shared. Those caches are used when you call Result.into(MyClass.class), > where the DefaultRecordMapper is looked up only once if you share the > Configuration, or every time, if you don't. There may be other caches in > the future. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/42c346a3-9747-4137-8530-16e94149534dn%40googlegroups.com.
