Basically Hibernate doubles back on itself because during a flush the identity to party name converter for AbstractParty column types tries to find an identity in the cache, misses, and attempts to look up in the database.
Now, this particular stack trace highlights that the fix to the concurrency problem Andras and I were trying to fix right before GA, where we flush the hibernate session just before a cache read can cause a cycle. It looks to me like there is a `SessionEventListener` that would allow us to detect that we are already mid-flush, and thus no need to flush again (or detach, which is why we needed the flush). This is my first plan of attack.
This simpler fix could still lead to hibernate being asked to load an identity during it's flush cycle. I have no idea what will happen if we do this. It will maybe just work. I think we can force this behaviour by having a state with a random generated anonymous identity in it that needs to be persisted (that isn't shared via the identity sharing flow, like it is in the normal cash flows).
If that simpler fix doesn't work, we perhaps need to look at giving the type converter a different session if a flush is in progress, pointing at the same database connection/transaction (we already supply the database connections to the sessions ourselves, so this would be possible I think). Anyway, more brainstorming on that if avoiding the nested flush doesn't totally fix it.
Seems like just adding the hibernate session listener to be aware of flushes works. Also added a test that triggers it. This should also be open source.