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.
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. On Wednesday, October 24, 2012 3:49:14 AM UTC-4, Ramon Smits wrote: > > > 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 > > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To view this discussion on the web visit https://groups.google.com/d/msg/nhusers/-/DX2f96z6SbwJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
