Here are the things we need from "temp table support":

1. The ability to export needed persistent and global-temp-table definitions to the database (MultiTableBulkIdStrategy#prepare currently).
2. The (configurable) ability to cleanup exported persistent and global-temp-table definitions from the database (MultiTableBulkIdStrategy#release currently).
3. The ability to export local-temp-tables "on demand"
4. The ability to clean up local-temp-tables after use if indicated by env.
5. The ability to execute inserts into the bulk-id table
6. The ability to use the bulk-id table in subselects

The first 4 all relate to managing the bulk-id table definitions. The last 2 relate to using the bulk-id table to perform the multi-table update/delete. The last 2 have a variation such that the persistent table case needs to manage a "session identifier" column whereas the local-temp-table and global-temp-table cases do not.

When we need to create/drop (manage) the bulk-id table definitions depends on the strategy in use. For persistent and global-temp strategies, this happens around the SessionFactory starting and stopping. For the local-temp strategy, this happens as we need the bulk-id tables (for each session). The part I struggle with is that in the one case (persistent and global-temp strategies) we can use the DDL immediately and not have to keep it around; in the second (local-temp strategy) we do. And the fact that this leaks outside of the strategy. One possible solution there is to have the local-temp strategy itself keep track of the necessary DDL per-entity rather than the persisters having to conditionally store it or not (leakage).

Dove-tailing into that, I think it also does not make sense for PersistentClass#prepareTemporaryTables to store its work on PersistentClass itself. I think a signature change is in order there to have that method return the Table. We can then pass those (singly or all-together) to the strategy for export and pass the name to the persisters for it to know.

I'd like to follow a similar pattern for the last 2 goals as well. The strategy ought to be the thing that drives the generation of the bulk-id table insert statement, the generation of the bulk-id table subselect and any binding of parameters (session identifier).