Whether or not you are comfortable with the use of hibernate in the face of complex business processing, as described in exception-found shared references to a collection

Let's talk about the project requirements first: because a Production Evaluation (estimation) may need data from an old version, as they can imagine, for example, this factory helped KFC to produce a batch of cake boxes last time. This is McDonald's order and a batch of cake boxes need to be produced. The size and process are similar to those of machines, but you need to dulicate it, and then go in and make some modifications. Therefore, we need to create a batch Bob in the background, and copy some data from the old data, probably from 9 tables, first query, and then insert. If Hibernate is not used, the logic is simple, query, and loop insertion. But later I found that

"Found shared references to a collection "!!!

It has been plagued by about one day, two people. Later, we found that the session and transaction are the two things starting from the beginning. Because our data is associated, lazy = false is set. Obtain the data first at the service layer. The method is probably like this.

Public void saveestaimtionfromoldversion (integer oldversionestimationid ){

List list = estimationdao. getestiamtionbyid (oldversionestimationid );

For (iterator it = List. iterator; it. hasnext ();){

// Processonerecord

// Save new data to 9 tables ......

}

}

This method is written in the service layer, and our transaction control with spring is also at this layer.

Everything works normally when debugging is passed, but the above error is reported when the thread leaves this method. Later, we suspected that the session did not release the data queried from the database. The official bean was called an unmanaged bean because it was always at the service layer and the session would never be flushed () note that the flush () action is controlled by spring; the session does not perform the flush () action, so the reference of which objects in the action always exists, because the new reference is new. Later, I made a change, that is, when the data is recycled out, the memory reference = NULL, so that everything is normal. however, such code is full of such business-independent code, which is at the cost of using hibernate.

Later, I changed the program.

 

Public void saveestaimtionfromoldversion (list oldestimation) {// This is not an integer, but a list

For (iterator it = oldestimation. iterator; it. hasnext ();){

// Processonerecord

// Save new data to 9 tables ......

}

}

Put the queried data action before the batchjob...

Everything is normal...

 

Another solution is to associate the features ---- remove all many2one and one2133 without using the hibernate cascade. In this way, the data queried through hql or SQL is normal. I guess the session will be specially processed if it is queried through SQL, and there will be no reference in the session.

Welcome to the discussion.