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 <st...@hibernate.org>
> > >>>>> http://hibernate.org
> > >>>>> _______________________________________________
> > >>>>> hibernate-dev mailing list
> > >>>>> hibernate-dev@lists.jboss.org
> > >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>>
> > >>> ---
> > >>> Steve Ebersole <st...@hibernate.org>
> > >>> http://hibernate.org
> > >>> _______________________________________________
> > >>> hibernate-dev mailing list
> > >>> hibernate-dev@lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > > ---
> > > Steve Ebersole <st...@hibernate.org>
> > > http://hibernate.org
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ---
> Steve Ebersole <st...@hibernate.org>
> http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
