When is "inverse=true" and when it's not?

When I was a hibernate beginner, I was confused about deciding "inverse=true" or "inverse=false".

Here is an easy way to understanding it:

example scenario:
Person(one) <-> Address(many)
* bi-directional one-to-many relationship. (A person has multiple addresses.)

public class Person {
  private Integer id;
  private Set
addresses;

  // setter, getter
  Set
getAddresses() { return addresses; }
  ....
}

public class Address {
  private Integer id;
  private Person person;

  // setter, getter
  Person getPerson() { return person; }
  .....
}

• Person class has "Set
  getAddresses()" method
• Address class has "Person getPerson()" method

If you think about the relation between two classes, it may gives an idea that person has addresses. (Person -> Addresses)
So, it feels like a person is an owner, and an address is a child. Then, you want to think that address is "inverse=true" because address is owned by person.
However, it's not correct.


Here, I'd like to suggest a way to think about it.

Let's look at table structure instead of classes.

• PERSON[ id, name, ...]
• ADDRESS[ id, person_id, city, street,...]

The person_id column in Address table is the relational information between thease two tables.
So, Address is an owner of the relationship, and Person is the inverse side.
"inverse=true" means "this side is the inverse side", and "inverse=false" means "this is not the inverse side. this side is the owner of the relationship".


Answer is:

  ...
  inverse="true">
    
    
  



  ...
  

In sum, look at the table structure to distinguish "inverse=true" or "inverse=false".
If the table has relational information, then it is the owner side. So, it's not inverse side.(inverse=false)
If the table doesn't have relational information, then it is the inverse side. So, it needs "inverse=true".

Read more ...

First and Second Level caching in Hibernate ?

1). First level cache

The sometimes so called "first level cache" is also known as the Session object, that you retrieve from the SessionFactory, sometimes delegating this to the HibernateUtil helper class.

This object is always used in Hibernate. It's the basis. You use it do anything that might have to do with the persistance of your objects.
It is also called first-level cache, because for example, if you ask for an object of the same id twice or more in a short time, it will return the already retrieved object each time, issuing only one query for that.
Obviously, as always with a cache, there're some caveats to be aware of (synchro with db, mostly), so that's why there're some patterns to follow :
The most important is that the session should be short lived and only used for a use case context. Never think using only one session for a whole app session, for example !
Session is not threadsafe, sessionfactory is. So be careful when using sessions objects in a multi-threaded environment.

2). Query cache

As explained, you use it only when you've got queries that have to be executed many times. Obviously not always, because the required overhead to cache the results has to be compensated by the next call performance boost. If you cache queries that are only once or twice called, you see that you're going to get the contrary result of what you want : better perfs.

3). Second level cache

Second level is to be used for never-modified objects. So you configure this only for some classes (i.e. tables) of your system. It is designed for always accessed objects. So use second level cache only for entities that never change.

OR

a) First-level cache
First-level cache always Associates with the Session object. Hibernate uses this cache by default. Here, it processes one transaction after another one, means wont process one transaction many times. Mainly it reduces the number of SQL queries it needs to generate within a given transaction. That is instead of updating after every modification done in the transaction, it updates the transaction only at the end of the transaction.
b) Second-level cache
Second-level cache always associates with the Session Factory object. While running the transactions, in between it loads the objects at the Session Factory level, so that those objects will available to the entire application, don’t bounds to single user. Since the objects are already loaded in the cache, whenever an object is returned by the query, at that time no need to go for a database transaction. In this way the second level cache works. Here we can use query level cache also. Later we will discuss about it.
Quoted from: http://www.javabeat.net/articles/37-introduction-to-hibernate-caching-1.html

Read more ...