Solutions for cocould not initialize proxy-No session errors in hibernate3 and lazy load Introduction

Cocould not initialize proxy-No session
Exception:
Org. hibernate. lazyinitializationexception: cocould not initialize proxy-No session
At org. hibernate. Proxy. abstractlazyinitializer. initialize (abstractlazyinitializer. Java: 57)
At org. hibernate. Proxy. abstractlazyinitializer. getimplementation (abstractlazyinitializer. Java: 111)

Cause:The default option of hibernate3 upload-to-one is lazy = "proxy"
Solution:Set lazy = "false" in <relative-to-one> & <set>"
The persistence object loading policy of hibernate.
Delayed loading, that is, loading only when used. This can improve some performance.
Hibernate's lazy loading uses a hibernatesession to manage a session. Its logic is to open a new session every time a database operation is performed. After the operation is completed, the session is closed immediately. The advantage of doing so is that you can strictly close the session to avoid cainiao errors, but hibernate.org does not recommend this. This is not suitable for lazy loading and cross-method transactions.

For example, in our application, user-> post forms a one-to-many ing, and user has a list containing post.
In User, there are multiple attributes: name, password, phone, etc, and a list posts. When we use lazy laoding for posts, Hibernate only Returns basic attributes such as name, password, and phone when obtaining the user object. When you access posts, it extracts the data required by posts from the database. This is called lazy laoding. However, in our system, the session is closed immediately, that is, after reading basic attributes such as name, password, and phone, the session has been closed, then perform lazy loaiding.
The solution is to call hibernate. initialize (user. getposts () before closing the session and tell the system that user. getposts () requires lazy laoding. However, this will destroy the encapsulation of the hibernatesession class.
Later, the so-called opensessioninview mode was used to hand over the session cycle to the servlet filter for management. Every time a request comes in, a session is opened, and the response is closed after it ends, this allows the session to exist throughout the request cycle.

Lazy delayed loading in hibernate
Hibernate is related to lazy on the parent end of one-to-one and others-to-one queries.
Hibernate3 has the lazy attribute in the association. If it is hibernate2, it should be set outer-join = "false" and then the associated object, set lazy = "true" in the class ". first, you can set lazy in the class label of the parent end to solve the issue of inter-to-one. In this way, no extra SQL statements will be sent when querying the son.
For one-to-one, in hibernate2, because one-to-one does not have the lazy option, you can only set outer-join = "false. Hibernate3 has been added to lazy, so this problem does not occur.
In general, if you find that there is excessive SQL sending when querying your son, it must be your misuse of hibernate ..

In hibernate's one-to-operate, feature-to-one, and feature-to-operate, we generally adopt the lazy mechanism to improve efficiency, however, use spring's gethibernatetemplate (). when saving (object), hibernatetemplate tries to get the session every time before execute, and tries to close the session after execution. That is to say, when the lazy of hibernate initializes the 1: n relationship, you must ensure that this link set is used within the same session, otherwise, hive will throw the exception of failed to lazily initialize a collection-No session or session was closed.

The Association settings of objects in hibernate are not flexible enough. In actual applications, lazy load is required, and in some cases, association is not needed. In hibernate, only one method can be set in the shadow file. For applications like ours, I am afraid to easily use open session in view (slower than lock ), it can only be either not set association or lazy = true. The previous classification information used only one classification to one relationship, and the cost was tolerable. But now the relationship is becoming more and more complex. If you add more information, the performance to be paid, I am afraid that the cost of bandwidth and other aspects will not be ignored. Even if the cache is used to improve the performance, the waste of bandwidth will not be forgiven.