I tested the recent multi-tenant code in hibernate 4 and it works well in the mode of the test case (manual session creation). Thanks guys, great work. My question is about support for what I see as the more normal usage of SessionFactory getCurrentSession(). Looking at the current code I cannot see a way to tell any of the SessionContext implementations to use a specific tenant id when building the session in getCurrentSession(). Is this something that is being looked at, or are we stuck with manual session creation to use the multi-tenant feature? Regards, Peter _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 20/06/2011 11:11 PM, Steve Ebersole wrote: > Good point. To be honest I have not thought much about it. Do you have > suggestion(s)? > > Not sure I much like overloading for getCurrentSession(String > tenantIdentifier) Doesn't make sense to me either. How about tenantId set on a ThreadLocal. That could work for JTASessionContext as well. > > On 06/20/2011 02:57 AM, Peter Yuill wrote: >> I tested the recent multi-tenant code in hibernate 4 and it works well >> in the mode of the test case (manual session creation). Thanks guys, >> great work. >> >> My question is about support for what I see as the more normal usage of >> SessionFactory getCurrentSession(). Looking at the current code I cannot >> see a way to tell any of the SessionContext implementations to use a >> specific tenant id when building the session in getCurrentSession(). Is >> this something that is being looked at, or are we stuck with manual >> session creation to use the multi-tenant feature? >> >> Regards, >> Peter _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

+1 for a CurrentTenantIdentifierResolver contract registered with the SessionFactory. This seems like a reasonably flexible approach. Donnchadh On 20 June 2011 15:06, Steve Ebersole<steve(a)hibernate.org> wrote: > If this were the direction, I'd rather suggest a > "CurrentTenantIdentifierResolver" contract registered with the > SessionFactory. > > Just brainstorming... this might also be usable from ConnectionProvider > and eliminate the need for > org.hibernate.service.jdbc.connections.spi.MultiTenantConnectionProvider > ... >>> >>> Not sure I much like overloading for getCurrentSession(String >>> tenantIdentifier) >> >> Doesn't make sense to me either. How about tenantId set on a >> ThreadLocal. That could work for JTASessionContext as well. >> _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev