+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.
>