JSP hibernate data saving operation Principle _jsp programming

Data save, update, and delete:
1, Session.save () method:
The Session.save () method is used for persistent storage of entity objects, which means that when the Session.save () method is executed, the corresponding insert SQL statement is generated, and the data is saved. As in the following code:
User User=new user ();
User.setname ("ZX");
Transaction tx=session.begintransaction ();
Session.save (user);
Tx.commit ();
When you execute to the Session.save () method, Hibernate does not immediately generate the INSERT SQL statement to save the data, but rather when you later clean the session's cache, it is possible to execute the INSERT SQL statement, then Session.save () What steps do the methods take? Take a look at the following summary:
First, in the session of the internal cache to find the Save object, if found, it is believed that the data has been saved (has performed the insert operation), the entity object is already in the persistent state, directly returned. At this point, even if the data has changed before the state, the dirty data checks will be checked to determine whether the update operation is required at the time of transaction submission.
Second, if the entity object implements the lifecycle interface, the OnSave () method of the object to be saved is executed.
Third, if the entity object implements the Validatable interface, the corresponding validate () method will be executed.
Iv. If there is a interceptor object, the Interceptor.onsave () method will be executed.
V. Construct the INSERT SQL statement to complete the data save.
After the data is saved successfully, the ID of the entity object is the ID of the inserted record.
(vii) Incorporate the saved entity objects into the Hibernate internal cache (first-level caching). Note that hibernate does not incorporate the saved entity objects into the level two cache, as the entity objects that have just been saved are likely to be modified later, the cache is frequently updated and the resulting synchronization problem is more than the benefit of caching the object.
Viii. finally if the object is associated with the object, the cascading object will be recursively processed.

1, Session.update () method:
I have previously said in the Entity Object State Transformation section that the Session.update () method can transform an object in a free state into a hibernate internal cache and become a persisted object. As in the following code:
Configuration cfg = new Configuration ();
Sessionfactory sf=cfg. Configure (). Buildsessionfactory ();
Customer Customer=new Customer ("ZX", 27,images);//customer objects in a Free State
Session session=sf.opensession ();

Transaction tx=session.begintransaction ();
Session.save (customer), after saving the Customer object in a persistent state
Session.flush ()//The Customer object is in a free state after emptying the cache
Tx.commit ();
Session.close ();

Session session2=sf.opensession ();
Transaction tx2=session2.begintransaction ();
Session2.update (Customer),//by calling the update () method to convert the Free State of the customer object to the persisted state again
Session2.delete (Customer)//after the Delete () method is called, the Customer object is removed from the cache when the cache is emptied, and a delete transaction is generated in the database to delete the data record for the customer object
Tx.commit ();
Session.close ();
So what steps does this approach perform? It will follow the steps below:
First, look for the entity object that needs to be updated in the cache, if found, return immediately, from here we can see that if you execute the update () method on an entity object that is already in persistent, it will not have any effect.
Second, then when the transaction is committed for cache cleanup, the changed properties are determined through dirty data checks, and then the update SQL statement is generated to complete the data.
Here's a question we'd like to emphasize is that as long as a free object is associated with the session via the update () method, the update SQL statement is executed regardless of whether the properties of the free entity object have changed. As in the following code:

Transaction tx=session.begintransaction ();
Session.update (customer);
Tx.commit ();
Session.close ();
No property values for the Customer object are modified in this code, but an update SQL statement is executed, and if you want to not execute the update SQL statement without changing the entity object attribute value, you open the entity object <class> element, set it to true, and this property defaults to "false". Select-before-update Configure as follows:
<class name= "Com.neusoft.entity.Customer" table= "Customer" select-before-update= "true" >
If this property configuration is enabled, a SQL statement similar to the following is executed first before the session cache is cleaned:
Select * from customer where id= ' 1 ';
The value of the attribute in the database for all the customer entities in the query is then compared to the value of the property in the cache, and if a change is made, an update operation is generated to update the data, and if no change is made, the update operation will not occur. To determine whether or not to turn this option on according to the actual requirements, if the entity object's properties do not change frequently, then this option should be turned on to avoid unnecessary update operations. If the properties of an entity object change frequently, there is no need to turn on this option to avoid executing an extra SELECT statement before the update operation.

Note: (1) when performing a session.update () operation on a free entity object, this operation throws an exception if there is no record of the entity corresponding to it in the database.
(2) when an Session.update () method is used to associate a free object with the session, this method throws an exception if there is already a persistent object in the cache that has the same OID as the entity object. Like the following code:
Customer Customer1=new Customer ("1", "ZX", 27,images);
Session session1=sf.opensession ();
Transaction tx=session1.begintransaction ();
Session.save (Customer1);
Session.flush ();
Tx.commit ();
Session1.close ();

Session session2=sf.opensession ();
Transaction tx2=session2.begintransaction ();
Customer othercustomer= (Customer) Session2.load (Customer.class, "1");
Session2.update (Customer1)
Tx2.commit ();
Session2.close ();
When the free object customer1 is associated with the Session2 again, a Othercustomer object with the same OID is loaded in the cache because of the load () operation, and the Customer1 At this point, an exception is thrown because the object caching mechanism of the hibernate cache does not allow the same object cache as the OID.
2, Session.saveorupdate ():
This method contains the features of the Save () method and the update () method, and if the method is passed a free object, the method performs an update operation, and if the method is passed in a temporary object, the method performs the insert operation. The method behind the scenes works as follows:
A) First in the cache, if you find the operation to be saved directly return.
b If the entity implements the interception method, then executes the isunsaved () method to determine the entity object state.
C executes save () if the entity is in a temporary state and executes update () If the entity is in a free state.
There is a problem here, that is, how does hibernate judge whether an entity is in a free State or is it temporary? If the entity satisfies one of the following conditions, the entity is considered to be in a temporary state.
. The OID value of the Java object is null.
. If the Java object has a version attribute (which will be explained in the Concurrent lock section) and is null.
. If the entity's <id> sets the property Unsaved-value, and the OID value is equal to the Unsaved-value value.
. If the version property of the entity has Unsaved-value set, and the value of the version property is equal to the Unsaved-value value.
. If the entity implements Interceptor, and the Interceptor.isunsaved () method returns True.
To satisfy one of these conditions, this entity is considered a temporary object.
3, Session.delete ():
The Delete () method deletes the data for one or a group of entities from the database, and if the incoming object is a persisted object, the delete operation is performed when the cache is cleaned up. If a free object is passed in, the object is first associated with the session, and then the delete operation is performed when the cache is cleaned up. Look at the following code:
Session session=sessionfactory (). Opensession ();
Transaction tx=session.begintransaction ();
Customer customer= (Customer) Session.load (Customer.class, "1");
Session.delete (customer);/plan to execute a DELETE statement
Tx.commit ()//clean cache, execute a DELETE statement
Session.close ()//closes the session, at which point the Customer object is removed from the cache.
If the customer object in the above code is a free object, when the Session.delete () method is executed, the free customer object is first associated with the session, and then the cache is cleaned before the delete operation is performed. If you want to delete more than one piece of data at a time, you can take an overloaded delete () method: Delete ("from Customer C where c.id> ' 8"); This method can delete all the data that matches the criteria.