[hibernate-dev] multi-tenancy and ConnectionProvider

[Emmanuel Bernard]

There is something that is escaping me. 

In your view, you would have one ConnectionProvider implementation per underlying multi-tenant strategy + connection lookup strategy?

ie 
JNDIDatasourceConnectionProvider (no multi tenancy support)
SchemaJNDIDatasourceConnectionProvider (multi tenancy with one tenant per schema)
VPDJNDIDatasourceConnectionProvider  (multi tenancy delegating isolation to the VPD tech)
And one could write a C3P0 alternative etc for these three if he is motivated.

Or is that something else?

Emmanuel

On 29 mars 2011, at 19:52, Steve Ebersole wrote:

> 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