Re: [nhusers] Potential pitfalls to using a shared SessionFactory in a multi-tenant application

[Ramon Smits]

There are several options.

1. Filters (filter data being read by using for example customer id, user id, etc.)

2. Sharding (split data over difference databases based on a sharding strategy)

Both just have one SessionFactory instance if I remember correctly. The biggest problem is that the SessionFactory also is the 1st level cache. Sharing splits data accross several databases. You could have a sharding strategy where you put data from customer A in database A. But my guess is that you some how just want to use a different connection for each customer.

I do now that you can pass a connection to a session. Maybe you can find out if it is possible to do use this but I can imagine that this could have impact on the 1st and 2nd level cache.

-- Ramon

[Alexander Kot]

Hello

We are using not 1 SF for each tenant but 1 SF per tenant based on common Configuration.
For us there 1 blocking feature to use shared SF - HiLo Id generator (both standard and extended)
HiLo generator for entity is global per SF not per session, so in case of MultiTenancy with shared SF it will be reused between tenants.
Solution is do not use HiLo or share it's table somehow  (1 schema per tenant + 1 schema with common data HILo, (in our case also logging table for log4net with tenant_id) )

[Ramon Smits]

On Wed, Oct 24, 2012 at 3:13 PM, Josh Earl <joshe...@gmail.com> wrote:

Thanks, Ramon. You are right--we want to use a different connection for each customer. Issues like caching are exactly what I'm concerned about. The worst case scenario I can think of is that making this change causes subtle breakage that goes unnoticed in our low traffic staging environment and then causes cross contamination of client data when deployed to production. 

If keys are unique accross databases then there should not be any problem.

 

My understanding is that implementing the IConnectionProvider interface allows connections to be switched on a per session basis. But if the sessions are using the SessionFactory as a cache, that only solves part of the problem. I'll have to look into that more thoroughly.

A session always behaves as a 1st level cache caching al retrieved objects within that session. The 2nd level cache is not enabled by default and this caching objects across session. You probably are not using 2nd level cache.

-- Ramon

[ggeurts]

The session factory does NOT act as first-level cache, that is the responsibility of the session. The main concern for data management is any use of the second-level cache if the same cache key is used for entities from different databases.