With the "native" Session now being effectively an EntityManager, this now behaves in all effects like an EntityManager and this includes refusing to flush any update out of a transaction boundary. Such a "strict" check was previously only applied to users of the HEM module but now it applies to Session too because of the inheritance.
This is probably a good thing, although it might be a migration issue for users of the native Session API so it might be nice to introduce a property which would allow people to still shoot themselves in the feet if they highly wish for it.
Let's not mince words
This is most definitely a bad behavior. We are temporarily adding a setting that continues to allow users to "shoot themselves in the foot" (as you mention) for 5.x. This will revert to not allowing the behavior in 6.0 as well.
+1 for having a setting. Can we emit a large red blinking warning if it is enabled
Would it be possible to log a warning including a stacktrace that allows to identify the location of the code that is doing this? The same would be useful for the "enable_lazy_load_no_trans=true" setting to investigate legacy code.
about the flag, assuming it is set to shoot me in the foot, will it also affect users that have bootstrapped Hibernate ORM via the JPA API ?
I am asking because before, I think the behavior was:
let out of tx flushes when Hibernate ORm was bootstrapped with the native APIs (e.g. Configuration)
throw the exception mandated by JPA when Hibernate ORM was bootstrapped via the Hibernate EM ways (pure JPA API or Ejb3Configuration etc)
It's not to alter the idea but more to get my head around it.
Two unit tests we have in Hibernate Search: