A conversation with Steve about the possible design:

<sannegrinovero> sebersole: is there an "auto-flush" event I could listen to?
<sebersole> org.hibernate.event.spi.AutoFlushEventListener
<sannegrinovero> as that issue about the Session.clear() method is far more complex than what I initially thought
<sannegrinovero> nice. Is that also fired if a user is performing an explicit Session.flush() ?
<sebersole> no
<sebersole> auto flush is a specific thing
<sannegrinovero> if you could bare my thoughts: the problem is that if a user does a clear() opertion, but somehow changes where already flushed to the DB, ...
<sebersole> yep
<sebersole> then you dont want to clear the index
<sebersole> was thining about that
<sannegrinovero> exactly, or I get out of synch anyway.
<sebersole> but my connection makes comms hard
<sebersole> well its a tough deal
<sannegrinovero> is there a specific event for flush() or could I add one like with clear() ?
<sebersole> there is a flush event too yes
<sannegrinovero> ah great.
<sebersole> org.hibernate.event.spi.FlushEventListener
<sebersole> there is also...
<sebersole> org.hibernate.event.spi.FlushEntityEventListener
<sebersole> which is the listener for each entity within a flush (no matter if auto or explicit)
<sannegrinovero> you agree that if I listen to both flush events & and hypotetical clear event then I should have enough info to do "the right thing" at TX commit?
<sebersole> do you have a notion of flushing the pending index updates?
<sannegrinovero> yes
<sebersole> other than transactionally
<sannegrinovero> we provide an explicit method for that, "flushToIndexes()"
<sannegrinovero> which forces a flush even if the transaction is not finished yet
<sebersole> but is that a transaction boundary thing?
<sebersole> so transaction still has an effect?
<sannegrinovero> it's similar to the Session.flush() with the important difference that it won't be cancelled by a TX rollback
<sebersole> well thats a very important diff
<sebersole> you really need something akin to our actionqueue
<sannegrinovero> right, but we can't do much about it, other than clearly document it.
<sebersole> a "staging" place for actions
<sannegrinovero> we have something like that, it's where we collect all events from the ORM listeners normally.
<sannegrinovero> it's then registered in a tx synch, so we "flush" it to indexes as an after-commit event.
<sebersole> but you need to know which have been flushed
<sebersole> in the orm sense
<sebersole> so you know what to do properly on clear
<sebersole> couple ways to attack this, but thats the crux
<sannegrinovero> my thought was that on a flush, we would receive a sequence of ORM events, so I collect all these in a block.
<sebersole> thats FlushEntityEventListener
<sebersole> you'd get one per entity being flushed
<sannegrinovero> ah I thought that ORM would flush all or nothing? Is it able to flush only a specific type?
<sebersole> well thats essentially what an auto flush is
<sebersole> we have a query that we know hits the table Animal, e.g.
<sannegrinovero> I see, so the "auto" one is somewat smar and flushes only the minimum needed to achieve consistency with queries, no more. Right?
<sebersole> so flush all entity changes that write to that table
<sebersole> yep
<sannegrinovero> cool, thanks I'll take it from here.
<sebersole> partial flush is a better name probably
<sannegrinovero> now that I know the bird's eye design it's much easier to handle. thanks
<sebersole> np
<sebersole> btw, FlushEntityEventListener is not per type
<sebersole> its literally per entity
<sebersole> each instance
<sebersole> Animal#1, Animal#2, ...
<sannegrinovero> great that makes it easier
<sannegrinovero> I can then literally "promote" each update task to a separate level where it's "protected" from clear()
<sebersole> exactly
<sebersole> thats my "staging"