Is there any performance benefit by using readOnly in hibernate criteria?

Question

I am using hibernate criteria API to retrieve data. These data will just viewed by user. User can not modify these data. So, Is there any benefit by using readOnly? Can you suggest the pros & cons? Is there any other measure I need to consider?

Read-only entities

Answer 1

Hibernate is tracking all objects loaded within the session to find the modifications and persist all the changes when you flush the session. If you load the entity as read-only, you instruct Hibernate not to trace that entity for changes. In that way, you will get some performance increase.

However, the object will stay in session cache. If the cache is too big, it becomes a big pefrormance issue, as well as you risk running out of memory. If you read many objects, it's good to evict them.

If the performance of Hibernate is really an issue, than switching to pure JDBC is a better option. I never use Hibernate for loading large amounts of data (such as for reports, or batch processing). For displaying lists I load only the fields I need, not the whole entities (if you read only chosen fields, and not whole entities, they are always read-only).

So the answer is, yes, it will make Hibernate a bit faster, but there are other ways of gaining even more performance.

Answer 2

Using read-only entities is more like a expression of intend. By using read only hibernate will not check if a entity has changed even if it has changed. This is different to entities marked as immutable since those are guarded against change. Hibernate will error out if it detects a immutable entity object's property has changed but not so for read-only entities.

So making an entity read only just informs hibernate that you do not want changes to be persisted. Also this may not be true in case of associated collections.

The performance gain is minimal unless you have special requirements or do a special expensive dirtiness check.

So it is not about performance. It is a safety measure that allows you to protect your database from unintended changes to objects.

For example you have a Location entity describing a geographical location. Now you have a person and assign a location to it. When loading the location using the persons association, you can make location read-only and even if your coworker (or yourself) accidently change the location by accident. The change will not be stored but changes to the Person entity will still be. (It may be best to mark location as immutable but there are those rare cases this is not sufficient.)