Hi! Starting with HHH-8487, when we execute a native query, an auto-flush is executed (and might be limited with addSynchronizedEntityClass and allegates). While I understand the rationale of this change, we are having a few issues with this when the transaction opened is read-only which is the case for all our read-only queries: Hibernate tries to flush the dirty entities in a read-only transaction and fails. The heart of the issue here is that we have dirty entities which shouldn't be dirty (see my post on embedded and dirtiness) but I'm wondering if it's a behavior which was missed by this patch or something intentional. So I thought I might as well report it. -- Guillaume _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Thu, Oct 30, 2014 at 2:56 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Personally having entities dirtied as part of a read-only transaction sounds > like an application bug to me. We could try to detect a read-only > transaction state (not sure how we'd do that across all cases) and > circumvent the flush there, but that would add unnecessary overhead to > applications that do the right thing. They aren't dirtied as part of the read-only transaction per se but I agree with you it's more an application bug (it's due to the way we're dealing with empty embedded). Just wanted to report it in case it was easy and free to test the transaction status!