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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org