1 Hibernate ?
- Navigation object graph retrieval
- OID search
- HQL search
- QBC search
- Local SQL search
2 Hibernate Java
transient: Not in the cache of the Session. Unsaved-value attribute value whose OID is null or equal to id
persistent: Add to Session cache.
detached: Has been persisted, but is no longer in the Session cache.
- Clean the cache is called
session.flush()the method. The call is cleared
- Session cleaning cache refers to synchronously updating the database according to the changes in the state of the objects in the cache, but not clearing the cache; clearing emptying the Session cache, but not updating the database synchronously.
4 load() get()
- If there is no object specified by OID in the database. By the get method to load, then returns a null; load by load, a proxy object is returned, if the code behind if you call the object of a property will throw an exception:
- load supports lazy loading, get does not support lazy loading.
- The JDBC access database code is encapsulated to simplify the tedious and repetitive code of the data access layer
- The flexibility of mapping, it supports a variety of relational databases, from one-to-one to many-to-many complex relationships.
- Non-invasive, transplantability will be good
- Cache mechanism: provide first level cache and second level cache
- Cannot optimize SQL
- The ORM principle is used in the framework, which causes the configuration to be too complicated
- The execution efficiency is deviated from that of native JDBC: especially in batch data processing
- Does not support batch modification and deletion
It is the best way to directly execute related SQl statements or call related stored procedures through the JDBC API
7 Hibernate OpenSessionView
- To solve lazy loading exceptions, the main function is to
Hibernate Sessionand request a thread binding together the full output until the page, so that you can ensure that the page read data when Session has been turned on, if you go to get too lazy loading objects No error will be reported.
- Problem: If you process data in large quantities in the business processing stage, it may cause the objects in the first-level cache to occupy too much memory and cause memory overflow. The other is the connection problem: Session and database Connection are bound together, if the business processing is slow can lead to lack of timely release of the database connection, resulting in the connection pool is not enough, so the larger the amount of concurrent projects not recommended for use in this way, consider using an urgent left outer join
(LEFT OUTER JOIN FETCH)or manually to the associated object is initialized.
8 Hibernate getCurrentSession() openSession() ?
- getCurrentSession() It will first check whether the Session is bound in the current thread, if there is, then return directly, if not created again. And openSession() is to directly new a new Session and return.
ThreadLocalto achieve isolation Session of the thread.
- getCurrentSession() will be done when the transaction is committed
Session, while openSession()
9 SQL ?
Call the doWork() method of Session.
Hibernate cache includes two categories: Hibernate level one cache and Hibernate level two cache:
- Hibernate level 1 cache is also called "
Session", it is built-in and cannot be uninstalled. Since the life cycle of the Session object usually corresponds to a database transaction or an application transaction, its cache is a transaction-scoped cache. In the first-level cache, each instance of the persistent class has a unique OID.
- Hibernate second-level cache is also called "
SessionFactory". Because the life cycle of the SessionFactory object corresponds to the entire process of the application, Hibernate second-level cache is a process-wide or cluster-wide cache. Concurrency problems may occur, so you need to use appropriate concurrency Access strategy, which provides transaction isolation level for cached data. The second level cache is optional and is a configurable plug-in. By default, SessionFactory will not enable this plug-in. When Hibernate accesses the data object according to the ID, it first checks it from the Session level one cache; if it is not found, if the second level cache is configured, then check it from the second level cache; if it is not found, then it queries the database, and the result According to the ID, when the cache is deleted, updated, or added, the cache is updated at the same time.