Batch processing of data refers to the processing of large amounts of data in a transaction.
In the application layer for bulk operations, mainly in the following ways:
- Through Session
- by HQL
- by statelesssession
- Through the JDBC API (as long as you use this, other as an understanding)
The Save () and update () methods of the session for batch operations will store the processed objects in their own cache. If you are working with a large number of persisted objects through a Session object, you shouldpurge objects that have been processed and no longer accessed from the cache in a timely manner. The specific practice isimmediately after processing an object or a small batch object, call the Flush () method to flush the cache, and then clear the cache in the call to the clear () method
Processing by Session is subject to the following constraints:
- You need to set the number of JDBC single batch processing in the Hibernate configuration file, ensuring that the number of batches of SQL statements sent to the database is consistent with the Batch_size attribute
- Hibernate cannot bulk insert at the JDBC layer if the object uses the "identity" identifier generator
- It is recommended to turn off Hibernate's level two cache when doing bulk operations
- Batch update: When a batch update is made, it is obviously undesirable to load all objects into the Session cache and then update one by one in the cache.
Using scrollable result set Org.hibernate.ScrollableResults, the object does not actually contain any objects, only cursors that are used to locate records online. Only when a program iterates through a particular element of a Scrollableresults object does it load the appropriate object into the database.
The Org.hibernate.ScrollableResults object is returned by the scroll method of Query
Bulk Operation via HQL
Note: HQL only supports INSERT into ... Insert statement in the form of SELECT, but does not support insert INTO ... The INSERT statement in the VALUES form. Therefore, the bulk insert operation cannot be performed using HQL.
Bulk operations via statelesssession in form, Statelesssession is similar to session usage. Statelesssession compared to the session, there are the following differences:
The
- Statelesssession does not have a cache, and objects that are loaded, saved, or updated by Statelesssession are in a free state. The
- Statelesssession does not interact with Hibernate's second-level cache.
- When you call the Save (), update (), or delete () method of Statelesssession, these methods execute the corresponding SQL statement immediately, and do not plan to execute only one SQL statement
- Statelesssession does not perform a dirty check, so after modifying the Customer object properties, you also need to call Statelesssession's update () method to update the data in the database. The
- Statelesssession does not perform any cascading operations on the associated object. The
- obtains two object memory addresses in different ways by loading the customer object with an OID of 1 through the same Statelesssession object two times. The actions of the
- statelesssession can be captured by the Interceptor interceptor, but will be ignored by Hibernate's event handling system.
public class Hibernatetest {private sessionfactory sessionfactory;private Session session;private Transaction transaction; @Beforepublic void init () {Configuration configuration = new Configuration (). Configure (); Serviceregistry serviceregistry = new Serviceregistrybuilder (). Applysettings (Configuration.getproperties ()) . Buildserviceregistry (); sessionfactory = Configuration.buildsessionfactory (serviceregistry); session = Sessionfactory.opensession (); transaction = Session.begintransaction ();} @Afterpublic void Destroy () {transaction.commit (); Session.close (); Sessionfactory.close ();} @Testpublic void Testbatch () {session.dowork (new work () {@Overridepublic void execute (Connection Connection) throws SQLException {///via JDBC native API, highest efficiency, fastest!}});}}
