I found that forcing FlushMode to MANUAL, since JTASessionContext defaults to flush before transaction completion, and calling flush() on update operations and finally commit() or rollback() is more flexible. Christian may argue that his approach is more efficient, and while I agree, I argue that it is impractical.

Andre

I’d be interested to hear your thoughts on ’session less’ ORMs such as Ebean.

It seems you just don’t like automatic (or help to do) *state* management. Again StatelessSession would give you full control; but you have declined that previously because it did too little.

As Christian points out there are ways in Hibernate to control this very explicitly (e.g. .setReadOnly).
FYI independent on your “series” we have been talking for a while about adding a session.setReadOnly(x) flag that you could use to get your “be-more-explicit-and-requires-more-user-code” approach.)

Your “series” seem to forget the downsides of your alternate approaches. Most users I have talked to actually gets very happy when they realize they don’t have to keep track on if a thirdparty library or code changed their objects; if they had to do that they would have to write alot more code and most likely that code would be much more inefficient (both in runtime and developer performance).

And yes, I’ve met people too that were surprised over some behavior but in general when they were explained why it was and what you would miss if it weren’t there peoples opinion turns.

And if that does not help them Hibernate still in many cases allow you to configure or use it the way you like - it is just not the way it works by default nor the way we document the most (since it would give alot of other issues)

No, it’s just you. Stop using “many others” as an excuse for your poor technical arguments. Apparently you don’t know what session.evict() and session.clear() are doing. Using these together with session.update() you can get your desired “I want to tell Hibernate to update explicitly” behavior. You can also disable automatic dirty checking and updating by disabling the snapshots in Hibernate with session.setReadOnly(o, true) or for all queried objects with query.setReadOnly(true). Your conclusions about refresh() are completely wrong, it is not used for what you think it is used. This stuff just doesn’t work as you think it should work.

No, there has already been one person who commented that they left Hibernate behind due to maintainability. Just because the opponents aren’t as vocal as I am doesn’t mean they aren’t out there. I know and have had long discussions with many folks who are not Hibernate fans.

I feel that you really missed the point of the post if you think that evict and clear will fix this issue. Remember that this is JPA and not Hibernate APIs and regardless I didn’t miss the point about refresh, it does exactly what is stated. Let’s look that them quick:

refresh (javadoc) - “Refresh the state of the instance from the database, overwriting changes made to the entity, if any.”

refresh (me) - “which essentially rolls back a single entity.”

clear (javadoc) - Clear the persistence context, causing all managed entities to become detached.

clear (me) - didn’t even mention it, but this would essentially make all the work I’ve done thus far worthless because everything would be detached and no longer lazy loadable or really usable as persistent entities.

Although I didn’t mention clear, my use of refresh was accurate.

Lastly, dirty checking would work, but again this is JPA. Still though, I might pass an Object to a library and not realize I need to set it to read only. What I’m saying is that the method of least surprise is to programmatically update objects via the persist or an update method and NOT via dirty checking. It is usually very difficult to track down if and where objects changed in large code bases (such as a few hundred codebases of a few hundred classes a piece).

To sum up, I know that many folks love Hibernate and feel that it solves all the worlds problems, but I’m being quite pragmatic and thinking about large and small code bases with large and small teams and the possibility of having junior or mid level developers working in the code.

No, it’s just you. Stop using “many others” as an excuse for your poor technical arguments. Apparently you don’t know what session.evict() and session.clear() are doing. Using these together with session.update() you can get your desired “I want to tell Hibernate to update explicitly” behavior. You can also disable automatic dirty checking and updating by disabling the snapshots in Hibernate with session.setReadOnly(o, true) or for all queried objects with query.setReadOnly(true). Your conclusions about refresh() are completely wrong, it is not used for what you think it is used. This stuff just doesn’t work as you think it should work.

Can you please stop this now and invest some more time in learning the basics?