We can fetch the associated entities wither eagerly or lazily. The fetch parameter can be set to FetchType.LAZY or FetchType.EAGER. EAGER tries to use outer join select to retrieve the associated object, while LAZY is triggers a select when the associated object is accessed for the first time. @OneToMany and @ManyToMany are defaulted to LAZY, and @OneToOne and @ManyToOne are defaulted to EAGER. The recommended approach is to use LAZY on all static fetching definitions and override this choice dynamically through JP-QL. JP-QL has a fetch keyword that allows you to override laziness when doing a particular query. This is very useful to improve performance and is decided on a use case to use case basis.
Named Queries
Though we can write queries in the code, externalizing them makes the code cleaner. - it eases debugging - Named queries are precompiled by Hibernate at start up time. Unfortunately, you lose the type-safety of queries written using the Criteria API.
Hibernate Locking Strategies
Optimistic Locking
Optimistic locking is a technique where you allow your application to perform updates hoping there won't be any simultaneous updates from another process, hence optimistic. Pessimistic locking is the technique where you assume there will be simultaneous updates from another process so you lock the data you are changing before any changes take place.
In Hibernate, optimistic locking is provided fairly seemlesly. You add a version field to your table and a version element to your mapping file. When you update a Hibernate object Hibernate will check the version values match. If they do the update is successful, and the version is incremented, if they are not Hibernate throws a StaleObjectException and you know that something else has updated your data.
Pessimistic Locking'
Pessimistic locking is provided by specifying a LockMode when you get an object from the database. If you get your object with the LockMode.UPGRADE for example Hibernate will use database specific SQL to lock the record (if your database supports it) such as "select ... for update". Now nothing can update that record till you are finished.
Hibernate Fetching Strategies
Pessimistic Concurrency Control
Hibernate assumes that two or more users want update the same record at the same time, so it prevents that by placing locks on the records. The lock is placed as soon as the any piece of row is accessed. other users might be able to read the data even though a lock has been placed.
Optimistic Concurrency Control
Instead of placing the lock on the whole record every time that is read, the system merely looks for an indication that two users actually did try to update the same record at the same time. If that evidence is found , then one user's updated are discarded and the user is informed. Hibernate maintains this using version on the columns. Each time the server reads a record to try to updates the server makes a copy of the version number of the record and stores that copy for later reference. When it is time to update the data back to the disk, the server compares the original version number that is read against the version number that the disk drive now contains. - a) If the version numbers are the same, no one else changed the record and the system can write the updated value. b) If the Originally read value and the current value on the dist are not the same, then someone changed the data since it was read, and the current operation is probably out of date. Thus the system discards the version of the data and gives the user an error message. Each time a record is updated, the version number is updated as well.
Comments
Post a Comment