Understand Hibernate's Flushmode.never

I. Background of the case:

Pictures from the movie "Born Killer"

Hibernate did not provide a good help for the massive data collection, which may have been considered less necessary by developers, and instead increased the complexity of the hibernate framework. So the concept of "maximum data volume = Batch processing", "Hibernate/java is not the best place to batch processing" in Hibernate development, some developers even directly using Hibernate to establish a session, Gets its connection and then makes JDBC operations. JDBC is not an antique, but in the hibernate call it again, it is inevitable some helpless. Recently, on the official jar of hibernate, I saw Gavin's "understand Flushmode.never" to the novice, referring to the blog of Tim, author of the Stripes Project (the fashionable project I have always been concerned about). After reading two people's comments, share with everyone.

Second, the performance of the killer?

The picture is from the movie "This killer is not too cold"

"My current DNA restructuring system, with its complex and massive OLTP data, deals with these complex objects (thousands of) in memory by relying on user interfaces (not batch processing) to implement use-case drivers," Tim wrote in his blog. "This is half a joke, I think of that delved life, really let every developer use abacus arithmetic?"

Session.setflushmode (Flushmode.never);

This statement is simple, but it solves the big problem. It tells the hibernate session not to flush any state changes to the database anytime, unless the developer calls Session.flush () directly. It sounds logical, but why does it affect performance in some scenarios, and in other scenarios it's like a feather?