[hibernate-dev] multi-tenancy and ConnectionProvider

Steve Ebersole steve at hibernate.org
Tue Mar 29 13:52:42 EDT 2011


Maybe i am just missing the point of  your specific passed values.

As currently implemented we really expect a custom ConnectionProvider to deal 
with the tenant identifier.  I really only see JNDI-based 
DataSourceConnectionProvider as something for which we might reasonable supply 
a implementation.  

To be honest the ConnectionProvider is not the difficult part to this.  The 
isolation within the Session and second level cache are by far the more useful 
things.

Of course I am open to suggestions here if anyone thinks we should provide 
support for concrete, tenant-aware ConnectionProviders out-of-the-box *and* 
has an idea what that looks like and how to actually do it in a clean way.

On Tuesday, March 29, 2011, at 12:36 pm, Emmanuel Bernard wrote:
> The reason I initially pushed the difference is because one could imagine
> some kind of map between the tenantId passed tot he session and the schema
> name that end up being used. But that might be a bit over engineered and
> the tenant id + tenantType (tenantStrategy is probably better) is enough
> info.
> 
> Emmanuel
> 
> On 29 mars 2011, at 18:30, Steve Ebersole wrote:
> > The connection provider is different yes.  The information needed is the
> > same.
> > 
> > For VPD you issues an ALTER SESSION command on the connection to tell it
> > the "tenant"
> > 
> > On Tuesday, March 29, 2011, at 11:22 am, Emmanuel Bernard wrote:
> >> Yes but on top of Oracle, I could use the VPD approach or the more
> >> portable but less integrated schema approach, right? Somehow the user
> >> will be able to chose and the connection provider will do different
> >> magic tricks. Or am I missing some step?
> >> 
> >> On 29 mars 2011, at 17:43, Steve Ebersole wrote:
> >>> VPD is really the same notion as a tenant.  So the ConnectionProvider
> >>> having access to the tenant already solves that
> >>> 
> >>> On Tuesday, March 29, 2011, at 10:31 am, Emmanuel Bernard wrote:
> >>>> For info, I like #2 the best
> >>>> 
> >>>> ConnectionOptions can deal in the future with:
> >>>> - schema based diff
> >>>> - user based diff ala Oracle VPD
> >>>> 
> >>>> interface ConnectionOptions {
> >>>> 
> >>>>  TenantType getTenantType();
> >>>>  String getDefaultSchema();
> >>>>  String getUser() //is that how VPD filters out?
> >>>>  ..some more techniques later
> >>>> 
> >>>> }
> >>>> 
> >>>> enum TenantType {
> >>>> 
> >>>> NONE,
> >>>> SCHEMA,
> >>>> USER
> >>>> 
> >>>> }
> >>>> 
> >>>> With getTenantType, a ConnectionProvider can return the right
> >>>> connection or yell if it does not support it. We could also imagine
> >>>> asking the ConnectionProvider to return the array of supported
> >>>> tenantTypes so that we can raise the exception at startup time.
> >>>> 
> >>>> On 22 mars 2011, at 22:21, Steve Ebersole wrote:
> >>>>> reference
> >>>>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-5697
> >>>>> 
> >>>>> For multi-tenancy implemented by sepaerate schema we need the ability
> >>>>> to tell the ConnectionProvider about the tenant for the given
> >>>>> getConnection() request. I really see 3 approaches to this:
> >>>>> 
> >>>>> 1) Have 2 hierarchies here.  The current ConnectionProvider contract
> >>>>> remains the same.  Add a new MultiTenantConnectionProvider with
> >>>>> methods accounting for tenant
> >>>>> 2) Just alter the ConnectionProvider contract to pass information in.
> >>>>> If we go this route I prefer the "parameter object" pattern where we
> >>>>> pass in ConnectionOptions interface (see issue).
> >>>>> 3) Use contextual lookup.  ConnentionProviders interested in (or
> >>>>> capable of understanding) mulit-tenancy would perform some kind of
> >>>>> "contextual" (ThreadLocal, etc) lookup for the needed information.
> >>>>> 
> >>>>> Thoughts?  Discussions?
> >>>>> 
> >>>>> ---
> >>>>> Steve Ebersole <steve at hibernate.org>
> >>>>> http://hibernate.org
> >>>>> _______________________________________________
> >>>>> hibernate-dev mailing list
> >>>>> hibernate-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> 
> >>> ---
> >>> Steve Ebersole <steve at hibernate.org>
> >>> http://hibernate.org
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> > ---
> > Steve Ebersole <steve at hibernate.org>
> > http://hibernate.org
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

---
Steve Ebersole <steve at hibernate.org>
http://hibernate.org



More information about the hibernate-dev mailing list