4:21 p.m.
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(a)hibernate.org>
http://hibernate.org
3:25 p.m.
I think for a user the best option (easiest to understand) would be 1).
3) is too magical. 2) is putting everything in one sack.
Adam
On Mar 22, 2011, at 10:21 PM, 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(a)hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Adam Warski
http://www.warski.org
http://www.softwaremill.eu
4:24 p.m.
But 3 is how it's done today since we don't have the other solutions.
So yeah it's magical, but people do manage to make it work. I will
concede that it is not always perceived as straightforward, however.
Something to think about in the grander scheme of things is how someone
would deal with obtaining a tenant-specific connection when resource
injection is in use. #3 solves this but what about #1 and #2? There
are some pretty neat things that I can envision wrt CDI but I haven't
thought through what the implementations would look like.
@Inject @TenantSpecific @UserDatabase private EntityManager em;
How would you drill the tenant information into the CP?
-CB
On 03/23/2011 04:25 PM, Adam Warski wrote:
I think for a user the best option (easiest to understand) would be
1).
3) is too magical. 2) is putting everything in one sack.
Adam
On Mar 22, 2011, at 10:21 PM, 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(a)hibernate.org>
> http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:58 p.m.
Well I think I am leaning towards a "parameter object" no matter what we do
otherwise. So call this param object interface ConnectionOptions. It would
have a single method today (err, tomorrow when I write all this :) to get the
tenant id.
The tenant id is really associated with the session. Either session
implements that interface or hands it off to a delegate it manages, but thats
the "scope"... the session.
So in your examnple, you would inject the entitymanager's session with the
proper tenant id. Ideally I want this to be specified up front when the
session is opended to make sure there is no possibility of changing it mid-
stream, but that further relies on
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2860
Anyway, in thinking about this sme more I think the way I really like is this:
1) ConnectionProvider remains as is
2) introduce a new provider contract (names as always are preliminary):
public interface SpecializedConnectionProvider extends ConnectionProvider {
public static interface ConnectionOptions {
public String getTenantIdentifier();
}
public Connection getSpecializedConnection(ConnectionOptions);
public void releaseSpecializedConnection(ConnectionOptions, Connection);
}
Having SpecializedConnectionProvider extend ConnectionProvider addressed
another issue I encountered when implementing this. How do you account for
situations where you need *some* connection? Like when reading
java.sql.DatabaseMetaData on "startup". The other option for that is to not
have SpecializedConnectionProvider extend ConnectionProvider (so they are back
to distinct hierarchies) and adding an extra method to
SpecializedConnectionProvider. This additional method would either give
access to a connection with out providing tenant information or if obtaining
java.sql.DatabaseMetaData is deemed the only acceptable use case there then
just have a method to scrape that info passing back DatabaseMetaData is not an
option if that is the decision because of
java.sql.DatabaseMetaData#getConnection
Also, I was not sure if there is really a need for a specialized "release this
connection" method in the case where SpecializedConnectionProvider extends
ConnectionProvider. There is still the ConnectionProvider#closeConnection
method. Now obviously if the herarchies are distinct we would need release
capability on both...
On Wednesday, March 23, 2011, at 04:24 pm, Chris Bredesen wrote:
But 3 is how it's done today since we don't have the other
solutions.
So yeah it's magical, but people do manage to make it work. I will
concede that it is not always perceived as straightforward, however.
Something to think about in the grander scheme of things is how someone
would deal with obtaining a tenant-specific connection when resource
injection is in use. #3 solves this but what about #1 and #2? There
are some pretty neat things that I can envision wrt CDI but I haven't
thought through what the implementations would look like.
@Inject @TenantSpecific @UserDatabase private EntityManager em;
How would you drill the tenant information into the CP?
-CB
On 03/23/2011 04:25 PM, Adam Warski wrote:
> I think for a user the best option (easiest to understand) would be 1).
>
> 3) is too magical. 2) is putting everything in one sack.
>
> Adam
>
> On Mar 22, 2011, at 10:21 PM, 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(a)hibernate.org>
>> http://hibernate.org
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
12:10 p.m.
Here is the other issue with "separate hierarchies"...
Code that deals with connections now becomes more complicated, having to first
see if there is a SpecializedConnectionProvider and if so grab a connection
from it, otherwise check the ConnectionProvider.
Obviously there are techniques to work around that like making all Connection
access route back through the Session which could expose a singular contract
for getting a connection. Then the "dirtiness" could be contained to just
that "thing".
On Wednesday, March 23, 2011, at 04:58 pm, Steve Ebersole wrote:
Well I think I am leaning towards a "parameter object" no
matter what we do
otherwise. So call this param object interface ConnectionOptions. It
would have a single method today (err, tomorrow when I write all this :)
to get the tenant id.
The tenant id is really associated with the session. Either session
implements that interface or hands it off to a delegate it manages, but
thats the "scope"... the session.
So in your examnple, you would inject the entitymanager's session with the
proper tenant id. Ideally I want this to be specified up front when the
session is opended to make sure there is no possibility of changing it mid-
stream, but that further relies on
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2860
Anyway, in thinking about this sme more I think the way I really like is
this:
1) ConnectionProvider remains as is
2) introduce a new provider contract (names as always are preliminary):
public interface SpecializedConnectionProvider extends ConnectionProvider {
public static interface ConnectionOptions {
public String getTenantIdentifier();
}
public Connection getSpecializedConnection(ConnectionOptions);
public void releaseSpecializedConnection(ConnectionOptions,
Connection); }
Having SpecializedConnectionProvider extend ConnectionProvider addressed
another issue I encountered when implementing this. How do you account for
situations where you need *some* connection? Like when reading
java.sql.DatabaseMetaData on "startup". The other option for that is to
not have SpecializedConnectionProvider extend ConnectionProvider (so they
are back to distinct hierarchies) and adding an extra method to
SpecializedConnectionProvider. This additional method would either give
access to a connection with out providing tenant information or if
obtaining java.sql.DatabaseMetaData is deemed the only acceptable use case
there then just have a method to scrape that info passing back
DatabaseMetaData is not an option if that is the decision because of
java.sql.DatabaseMetaData#getConnection
Also, I was not sure if there is really a need for a specialized "release
this connection" method in the case where SpecializedConnectionProvider
extends ConnectionProvider. There is still the
ConnectionProvider#closeConnection method. Now obviously if the
herarchies are distinct we would need release capability on both...
On Wednesday, March 23, 2011, at 04:24 pm, Chris Bredesen wrote:
> But 3 is how it's done today since we don't have the other solutions.
> So yeah it's magical, but people do manage to make it work. I will
> concede that it is not always perceived as straightforward, however.
>
> Something to think about in the grander scheme of things is how someone
> would deal with obtaining a tenant-specific connection when resource
> injection is in use. #3 solves this but what about #1 and #2? There
> are some pretty neat things that I can envision wrt CDI but I haven't
> thought through what the implementations would look like.
>
> @Inject @TenantSpecific @UserDatabase private EntityManager em;
>
> How would you drill the tenant information into the CP?
>
> -CB
>
> On 03/23/2011 04:25 PM, Adam Warski wrote:
> > I think for a user the best option (easiest to understand) would be 1).
> >
> > 3) is too magical. 2) is putting everything in one sack.
> >
> > Adam
> >
> > On Mar 22, 2011, at 10:21 PM, 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(a)hibernate.org>
> >> http://hibernate.org
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
10:31 a.m.
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(a)hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
10:43 a.m.
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(a)hibernate.org>
> http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
11:22 a.m.
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(a)hibernate.org>
>> http://hibernate.org
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:30 a.m.
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(a)hibernate.org>
>>> http://hibernate.org
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ---
> Steve Ebersole <steve(a)hibernate.org>
> http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
12:36 p.m.
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(a)hibernate.org>
>>>> http://hibernate.org
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> ---
>> Steve Ebersole <steve(a)hibernate.org>
>> http://hibernate.org
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
12:52 p.m.
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(a)hibernate.org>
>>>>> http://hibernate.org
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>> ---
>>> Steve Ebersole <steve(a)hibernate.org>
>>> http://hibernate.org
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ---
> Steve Ebersole <steve(a)hibernate.org>
> http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
3:39 p.m.
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(a)hibernate.org>
> >>>>> http://hibernate.org
> >>>>> _______________________________________________
> >>>>> hibernate-dev mailing list
> >>>>> hibernate-dev(a)lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>> ---
> >>> Steve Ebersole <steve(a)hibernate.org>
> >>> http://hibernate.org
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > ---
> > Steve Ebersole <steve(a)hibernate.org>
> > http://hibernate.org
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
5018
days inactive
5025
days old
11 comments
4 participants
participants (4)
-
Adam Warski -
Chris Bredesen -
Emmanuel Bernard -
Steve Ebersole