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 On 06/20/2011 08:45 AM, Peter Yuill wrote: > 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@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
