We are seeing this too in your documentation tests. So its ok to just change those to wrap the writes/flushes in a transaction? (they are not now)
On Tue, Apr 26, 2016 at 10:09 AM Vlad Mihalcea <mihalcea.v...@gmail.com> wrote: > Hi, > > It's fine if we stick to the JPA spec so that only read ops are allowed to > be executed outside of a transactional context. Most applications use > either Java EE or Spring, so transaction boundaries are usually enforced > anyway. > > It's also fine to throw an exception if the object being checked within > the Persistence Context is not an entity. This might break some existing > use cases, but we are covered by the JPA spec :D > > In the getTransaction() case, I still believe we should offer two > strategies: a JPA and a native one, the choice being made based on the > current bootstrap procedure or some configuration property. > > Vlad > > On Tue, Apr 26, 2016 at 5:53 PM, Steve Ebersole <st...@hibernate.org> > wrote: > >> 2. "Another change in expectation is in regards to operations outside of >>> a transaction" - in JPA we can execute queries outside a transaction, >>> but any write will fail if there is no transactional context, which is >>> reasonable for me too. If Hibernate allows writes outside of a >>> transactional context, that's definitely a thing we should not support >>> anyway. >>> >> >> Well we'll agree to disagree about the validity of allowing queries >> outside the scope of a transaction; it does not matter, because JPA says it >> should be allowed, so we have to allow that. >> >> However, historically Hibernate allowed writes outside the scope of a >> transaction as well (auto-commit support), so that is what I am talking >> about. After pulling over HEM logic we now have some test failures due to >> tests trying to write data outside of an explicit transaction ( >> javax.persistence.TransactionRequiredException). >> >> So I propose we continue to expect that as a failure starting in 5.2. >> For queries we will continue to supports it, but only because JPA requires >> us to; not because it is a valid concept. >> >> >> >>> 3. "Asking a Session if is contains (Session/EntityManager#contains) a >>> non-entity" - we can handle this with the separate exception handler >>> strategies to retain both JPA and Hibernate behaviors. >>> >> >> Why? This is exactly the kind of thing I have in mind when I talk about >> the unnecessary complexity. Clearly asking if the Session contains a >> boolean e.g. is complete non-sense. If JPA requires that condition to >> throw an exception, why even worry about the other case? >> >> >> >> >>> 4. "Accessing Session/EntityManager#getTransaction. JPA says that is >>> only allowed for JDBC transactions. Hibernate always allows it." - I'd >>> choose the Hibernate behavior because I don;t see how it can cause any >>> issue and it's an enhancement as well. >>> >> >> Well that's great in principle. But JPA actually requires an exception >> be thrown when #getTransaction() is called in the JTA case. So there is no >> simple "just allow it as an extension" solution, we'd have to specific >> allow users to opt-in to allowing that. >> >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
