Support for multi-tenancy

[danstooamerican]

We are developing a service that supports multi-tenancy. One schema per tenant is created using the available JPA features for multi-tenancy.

Issues arise with the current implementation of the EventPublicationRegistry. For this feature to work, all registry entries must be in the same schema and cannot be spread across different tenant schemas. We worked around this by configuring custom entity and transaction managers. The default entity and transaction managers are picked up by Modulith. These are not configured with any multi-tenancy features which works just fine. The second set of entity and transaction managers are configured with multi-tenancy features and are used by our application.

This setup works just fine for the happy path. However, if a transactional event handler fails and the event is retried on restart, it is published with the wrong transaction manager. Thus, the wrong schema is selected by our code and the required tables are not found.

Is there any way that configuring multi-tenancy with Modulith can be simplified? We would greatly appreciate any information on how to support multi-tenancy with Modulith.

I am not very experienced with entity and transaction managers. I feel like a simple configuration for the used transaction managers that are used by Modulith could go a long way. So one transaction manager for the event publication registry and another one for publishing retried events.

[simasch]

I currently have the same issue. I use schema-based multi-tenancy. For that to work, the table event_publication must have a column tenant that is then used to set the TenantContext (ThreadLocal in my case).

Do you have any plans to support multi-tenancy?

[odrotbohm]

I don't think there's a need for dedicated multi-tenancy support in Spring Modulith. The primary challenge is to transfer the thread-bound tenant identifier into the threads that are used for the async invocation. A recommended approach to that is to register a ThreadPoolTaskExecutorCustomizer (alternatively a SimpleAsyncTaskExecutorCustomizer if you're using virtual threads). That will in turn register a TaskDecorator on the executor, that can obtain the tenant identifier and re-populate your thread-based tenant identifier infrastructure in the runnable about to be executed on the other thread:

class MyForwardingTaskDecorator implements TaskDecorator {

  public Runnable decorate(Runnable runnable) {

    var tenantId = … // lookup tentant identifier from thread

    return () -> {
       // Set tenant identifier on thread before calling…
       runnable.run();
    };
}

[simasch]

Oh yes this work 👍
Thanks a lot!

[odrotbohm]

Multi-tenancy in Spring applications is usually implemented in a DataSource per tenant approach and a custom AbstractRoutingDataSource that would select a DataSource by tenant id.

[danstooamerican]

We also use a schema per tenant approach. The "problem" with modulith is that all events are stored in a single table. Thus, the events must be stored outside of the tenant schemas. We found a setup that works but some guidelines and best practices to solve this would be great. We haven't run into any problems yet but we also don't use events that much currently.

[simasch]

Really? I almost always did schema per tenant as very often the schemas are created on the fly when a new tenant registers.
I use MultiTenantConnectionProvider and CurrentTenantIdentifierResolver.

Whatever the implementation is, how do you solve the problem that the thread that is consuming the events is not tenant-aware?

[danstooamerican]

We introduced a TenantAware interface that forces us to include a tenant identifier in every event. We register an aspect that wraps around event handler methods and initializes the tenant context using the interface. This works really well but we need to ensure that the interface is properly implemented. If events could natively support metadata, we could write a wrapper around the event publication that adds the necessary data.

[odrotbohm]

I guess this was supposed to be a reply to my answer. Yes, it is indeed the preferred approach, as any other third-party library is out of scope from a core Framework perspective. MTCP and CTIR are not even part of JPA, but Hibernate specific. Not saying, those are not a good choice. Just explaining, why ARDS is considered the primary means from a Spring perspective. Plus, it's pretty flexible as it can hide a schema-per-tenant approach but also a database-per-tenant one.

[simasch]

@odrotbohm Thanks for the explanation. My problem is that I cannot use ARDS.

[goranpetrovikj]

@danstooamerican Can you please share an example of an event implementing such TenantAware interface?

[danstooamerican]

We are glad to share. The magic happens in the InitializeTenantContextForEventHandlersAspect that uses the TenantAwareEvent interface to extract the relevant data and initializes the tenant context. The remaining code only needs to ensure that all events implement this interface. The rest is transparent to the developer and is performed in the background. This also works if a failed event is reapplied.

public interface TenantAwareEvent {
    String tenantId();
}

@Aspect
@Component
public class InitializeTenantContextForEventHandlersAspect {
    @Before("(@annotation(org.springframework.modulith.events.ApplicationModuleListener) || @annotation(org.springframework.context.event.EventListener)) && args(event,..)")
    public void initializeTenantContextBeforeHandler(TenantAwareEvent event) {
        // initialize tenant context
    }
}

record SomethingHappenedEvt(
    String tenantId,
    ...
) implements TenantAwareEvent { }

@ApplicationModuleListener
public void on(SomethingHappenedEvt event) {
    // your custom logic with an initialized tenant context because the aspect runs before the invocation
}