Multitenancy Support for Drools

[Nilima Gawade]

Hi All,

Please advice how to handle Multitenancy in Drools ?

Multitenancy Support for Drools:

Separate KieSession for Each Tenant or Shared KieSession with Tenant Isolation ??

I am new to drools recently started exploring it.

Thanks,

Nilima

[Ajay Chowdary Kandula]

Handling multitenancy in Drools can be approached in two primary ways: using separate `KieSessions` for each tenant or a shared `KieSession` with tenant isolation. Each approach has its pros and cons, depending on your specific use case and requirements.
Option 1: Separate `KieSession` for Each Tenant
This approach involves creating a dedicated `KieSession` for each tenant.
Advantages:
1. Complete Isolation: Each tenant operates independently, ensuring no data or state leakage between tenants.
2. Customizability: Rules and configurations can be tailored per tenant without affecting others.
3. State Management: Stateful sessions can maintain tenant-specific data without interference.
Disadvantages:
1. Resource Intensive: Maintaining separate sessions for each tenant can consume more memory and processing power, especially with a large number of tenants.
2. Complexity: Managing multiple sessions (e.g., creating, destroying, and maintaining them) adds operational overhead.
Implementation Example:
• Use a map to associate tenants with their respective session IDs.
• Persist the sessions in a database (e.g., JPA) for recovery after application restarts.

private final Map<String, KieSession> tenantSessions = new HashMap<>();

public KieSession getOrCreateSession(String tenantId) {
return tenantSessions.computeIfAbsent(tenantId, id -> {
KieServices kieServices = KieServices.Factory.get();
KieContainer kieContainer = kieServices.getKieClasspathContainer();
return kieContainer.newKieSession();
});
}

Option 2: Shared `KieSession` with Tenant Isolation
This approach uses a single shared `KieSession`, but ensures tenant isolation through mechanisms like filtering by tenant ID or using global variables.
Advantages:
1. Resource Efficiency: A single session reduces memory usage and simplifies session management.
2. Scalability: Easier to scale for applications with many tenants.
Disadvantages:
1. Risk of Data Leakage: Tenant-specific data must be carefully isolated to avoid accidental sharing.
2. Limited Customization: All tenants share the same rules, which may not suit applications requiring tenant-specific logic.
Implementation Example:
• Use a global variable or fact that includes the `tenantId` to filter rules and facts.
• Ensure every rule checks the `tenantId` before execution.

ksession.setGlobal("currentTenantId", "tenant123");

// In your DRL file
rule "Example Rule"
when
$fact : Fact(tenantId == currentTenantId)
then
// Rule actions
end

Factors to Consider When Choosing an Approach
1. Number of Tenants: For a small number of tenants, separate `KieSessions` may be manageable. For many tenants, shared sessions are more practical.
2. Data Sensitivity: If strict data isolation is required (e.g., regulatory compliance), separate sessions are safer.
3. Resource Constraints: Shared sessions are better suited for environments with limited resources.
4. Customizability Requirements: If tenants require significantly different rules, separate sessions are more appropriate.
Conclusion
• Use separate `KieSessions` if you prioritize isolation and customizability over resource efficiency.
• Opt for shared `KieSessions` if you need scalability and have mechanisms to ensure proper isolation (e.g., tenant-specific filtering).

Thanks and Regards!!!
Ajay C. Kandula

maila...@gmail.com
+1-614-329-9276

” Confidential: The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, please immediately alert the sender by reply e-mail and then delete this message. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. We have taken every reasonable precaution to minimize the risk but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. “

--
You received this message because you are subscribed to the Google Groups "Drools Usage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/drools-usage/34a8ff77-fdd7-43e5-bd95-f179dff12a1cn%40googlegroups.com.

[Nilima Gawade]

Thanks for the inputs .

As discussed in email

Right now I am at POC stage but still I can answer few questions:

• Are you using stateful or stateless sessions?I am planning to use stateful sessions

• What kind of issues have you observed (e.g., inconsistency, performance)?What if DRL file changes in the middle of session /How to handle large data sets?

• How many tenants are you supporting? around 4 to 5

• What level of isolation do your tenants require? as of today Tenants have separate instances of the application and databases

[Ajay Chowdary Kandula]

Thank you for providing additional details about your POC stage and setup. 

Based on your responses:

1. Since you plan to use stateful sessions, I recommend creating separate `KieSessions` for each tenant (given there are only 4–5 tenants). This aligns well with your existing architecture where tenants have separate application instances and databases.

2. Regarding DRL file changes during an active session:
• You can rebuild the `KieBase` and create new sessions when rules change.
• Alternatively, consider versioning your rules and migrating tenants/sessions gradually to updated versions.

3. For handling large datasets:
• Process facts in batches instead of inserting all at once.
• Optimize your rules to avoid complex joins or conditions that scan large datasets repeatedly.
• Dispose of unused sessions promptly to free up resources.

4. Given that tenants require isolation today, separate sessions ensure complete independence while simplifying debugging and customizations.
Let me know if you’d like further clarification or assistance with implementation details!

Thanks and Regards!!!
Ajay C. Kandula

maila...@gmail.com
+1-614-329-9276

To view this discussion visit https://groups.google.com/d/msgid/drools-usage/7c019437-7138-4ac3-8618-909a08205d3fn%40googlegroups.com.

[Nilima Gawade]

Thanks Ajay 

I have gone through all basics of drools so much better than last week but still I have few questions :)

For using separate session for each tenants , 

1.I am trying to understand how to fit this in microservices?

2.How to load DRL files ? in memory? what will be the issues

Please share your thoughts on this , or  share if you have done any POC on this .Thank you for your help.

Thanks,

Nilima