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