i think i have a solution now, that should be ok

i load the Configuration globally, and only once for the application, and 
without any request-specific configs.
- 
https://github.com/funkrusher/fk-framework-quarkus-jooq/blob/main/fk_core/src/main/java/org/fk/core/jooq/ConfigurationFactory.java

I changed the Execution-Listener so it uses the "ctx.dsl().data" object to 
get the tenantId.
- 
https://github.com/funkrusher/fk-framework-quarkus-jooq/blob/main/fk_core/src/main/java/org/fk/core/jooq/FkExecuteListener.java

i create the DSLContext instances on demand, and add a given tenantId to 
the "ctx.dsl().data".
https://github.com/funkrusher/fk-framework-quarkus-jooq/blob/main/fk_core/src/main/java/org/fk/core/jooq/DSLFactory.java

all Dao-Instances will be given the DSLContext or dsl.transaction instances 
to work with, and have also access to "dsl().data" to get the tenantId if 
needed.


Bernd Huber schrieb am Mittwoch, 27. März 2024 um 10:44:32 UTC:

> sorry, i overread the part where you explained about adding data() to the 
> TransactionContext instead. 
> I will think about how i could make use of that!
>
>
> lukas...@gmail.com 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 <
>> jooq...@googlegroups.com> 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 jooq-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jooq-user/2ec0ad1b-70ff-4194-b181-9e756b8c8cean%40googlegroups.com.

Reply via email to