Note that to support the concurrent stacks (from different sessions), there are two main strategies:

• a ThreadLocal

• a weak-key based concurrent hashmap (Jason's implementation)

In an ideal world, we would keep the stack of operations per session but today, I don't know a way on ORM to attach arbitrary data to a session.

As discussed this morning,

emmanuel you will see how we append the HSearch custom listeners to the configuration 09:35
emmanuel so in OGM's case we will need to replace more than append (and be careful) but that's the idea 09:35
emmanuel basically by using a similar code in OgmIntegrator you can get going 09:36
gscheibel is the order into OgmIntegrator.prepareServices() important ? 09:39
emmanuel gscheibel: no I don't think so 09:43
gscheibel ok (prefer to be sure) 09:43
emmanuel I don't think you need to touch prepareServices though 09:44
emmanuel it seems interate i all youo need 09:44
gscheibel so it's in JTATransactionManagerTransaction 09:46
gscheibel I'll find where I have to start 09:46
gscheibel I don't despair 09:47
emmanuel gscheibel: What do you want to touch in JTATransactionManagerTransaction 09:48
emmanuel ? 09:48
emmanuel As i said yesterday, the batch feature should have nothing to do with transactions 09:48
emmanuel The integration point is OgmIngetrator.integrate 09:48
emmanuel and you need to add a custom Listener for Flush and auto flush operations 09:49

What I had in mind is pretty clear in my head let me try and clarify it here.

On the dialect API, add two methods prepareBatch(eventsource) and executeBatch(eventSource).
eventsource is more or less a session object but from within Hibernate ORM. You need eventsource to differentiate one batch from a concurrent batch of a different session. Remember that dialects are accessed concurrently

Each Dialect method will also receive the eventsource to properly add the operation to the right batch

prepareBatch and executeBatch should be called before and after onFlush / onAutoFlush

That means that today the Dialect will be responsible for setting operations to the right batch and be thread safe. An alternative design can be to queue change from within Hibernate OGM and then call the dialect with a Set<Operations> but let's do this design in a later phase.

Note that the dialect might return data when updating things and this might limit the batch ability but I have no real visibility just yet. Let's cross fingers.

Summary of a discussion on IRC

if you look at FlushEventListener, basically you could hook the right calls in there

that's probably the easiest way
you also need to deal with AutoflushEventListener to be complete
Though delegation might not work for auto flushes as you have not checked if flush was really needed.
If the prepare and ask phase of the dialect for an empty workset is very lightweight, that's not a problem and the delegation can still work.

Right for all data stores.