There is a similar problem with regard to sequences as well. The problem is the notion of caching of values in memory via the optimizers. The optimizers are not tenant aware. Really the generators themselves are not tenant aware either, they just happen to work because we use Connections specific to each tenant schema as part of the Session.

So the question becomes how we best address this:

1) Handle tenancy in the generators
2) Handle tenancy in the optimizers.
3) Handle tenancy in the persister; e.g., getIdentifierGenerator() becomes getIdentifierGenerator(String tenant).
4) Expect the table backing the generator to hold a tenant identifier (discrimination)

(4) is not a good general-purpose solution; it would not be applicable to sequences for example. I don't think (3) is the most natural fit.

For review, the basic generator contract is defined as generate(SessionImplementor session, Object object). `object` is the thing (usually the entity) for which we are generating an identifier. We are also passed the session. The session knows the current tenant (if one). So both (1) and (2) already have the information needed.

I am going to attempt (2) first, as I think it is the least disruptive and would also cover any custom generators using optimizers.