We Keep Coding

Hibernate Session vs Transaction

I'm a bit confused about the concept of Sessions and Transactions in Hibernate.
As far as i understand, Hibernate uses Sessions (Persistence Context), which is basically a Cache for Entitys that need to be persist, deleted or whatever in the Database.
Sessions encapsulate Transactions, so i start a Session, followed by creating a Transaction. After the Transaction is closed, everything from the Persistence Context is flushed to the Database.The same thing will happen, if i close the Session.
Why do i need both? Can i do the same without creating a Transaction?

First of all, you can open more than 1 transaction within the same session.
Now, flushing doesn't necessarily relate to transaction commit. When you save() an entity - it'll be flushed if you use Identity generation strategy. When you select something - Session will also flush (if flush mode is AUTO). And you can even tell Hibernate not to flush before transaction commits (flush mode MANUAL).
Transactions are only responsible for ACID, it's a DB feature. While Session is responsible for managing entities, generating SQL, handling events. It's a Java thing.
PS: Session isn't just a "cache". It's also a way to track which entities are changed. So it's more than just an optimization trick.

after session1.close(), session2 getting objects from cache in hibernate

I have heard that after session.close() , the objects are in this session will be removed from cache.
If 'yes'
then why 'session2' object retrieving object from cache?
I am closing 'session1' when I'm fetching data first time(query executing) and data will be stored in cache(default first level cache), RIGHT !
But, after creating 'session2' object, I'm still able to retrieve particular object(no query is executing), means it is taking object from cache !
....Why ?
In image, I have paste my code
Image : my java files, table, persistent class, output

There are cache leves in Hibernate that you need to understand.
First-level cache:
The first-level cache is the Session cache and is a mandatory cache
through which all requests must pass. The Session object keeps an
object under its own power before committing it to the database.
Second-level cache:
Second level cache is an optional cache and first-level cache will
always be consulted before any attempt is made to locate an object in
the second-level cache. The second-level cache can be configured on a
per-class and per-collection basis and mainly responsible for caching
objects across sessions.
Query-level cache:
Hibernate also implements a cache for query resultsets that integrates
closely with the second-level cache.
All is quoted from here Cache Hibernate Tutorial. So in short the First Level of cache of that Session is removed. But that doesn't mean that the other Session Cache or the Level 2 cache need to be removed, because has his own Cache. Hope it helped you.

Spring Transaction Isolation Level

Most of us might be using Spring and Hibernate for data access.
I am trying to understand few of the internals of Spring Transaction Manager.
According to Spring API, it supports different Isolation Level - doc
But I couldn't find clear cut information on which occasions these are really helpful to gain performance improvements.
I am aware that readOnly parameter from Spring Transaction can help us to use different TxManagers to read-only data and can leverage good performance. But it locks the table to get the data to avoid dirty-reads/non-committed reads - doc.
Assume, in few occasions, we might want to blindly insert the records into a table and retrieve the information without locking the table, a case where we never update the table data, we just insert and read [append-only]. Can we use better Isolation to gain any performance?
As you see from one of the reference links, do we really require to implement/write our own CustomJPADiaelect?
What's the better Isolation for my requirement?

Read-only allows certain optimizations like disabling dirty checking and you should totally use it when you don't plan on changing an entity.
Each isolation level defines how much locking a database has to impose for ensuring the data anomaly prevention.
Most database use MVCC (Oracle, PostgreSQL, MySQL) so readers don't lock writers and writers don't lock readers. Only writers lock writers as you can see in the following example.
REPEATABLE_READ doesn't have to hold a lock to prevent a concurrent transaction from modifying your current transaction loaded rows. The MVCC engine allows other transactions to read the committed state of a row, even if your current transaction has changed it but hasn't yet committed (MVCC uses the undo logs to recover the previous version of a pending changed row).
In your use case you should use READ_COMMITTED as it scales better than other more strict isolation levels and you should use optimistic locking for preventing lost updates in long conversations.
Update
Setting #Transactional(isolation = Isolation.SERIALIZABLE) to a Spring bean has a different behaviour, depending on the current transaction type:
For RESOURCE_LOCAL transactions, the JpaTransactionManager can apply the specific isolation level for the current running transaction.
For JTA resources, the transaction-scoped isolation level doesn't propagate to the underlying database connection, as this is the default JTA transaction manager behavior. You could override this, following the example of the WebLogicJtaTransactionManager.

Actually readOnly=truedoesn’t cause any lock contention to the database table, because simply no locking is required - the database is able to revert back to previous versions of the records ignoring all new changes.
With readOnly as true, you will have the flush mode as FlushMode.NEVER in the current Hibernate Session preventing the session from committing the transaction. In addition, setReadOnly(true) will be called on the JDBC Connection, which is also a hint to the underlying database not to commit changes.
So readOnly=true is exactly what you are looking for (e.g. SERIALIZED isolation level).
Here is a good explanation.

What's the difference between L1 and L2 caches in web-applications with Hibernate as ORM mechanism?

I just want some general info about standard purpose of using L1 cache and L2 cache.
I'm curious because I'm investigating the system with terracotta as 2nd level cache and I've found that it also has 1st-level cache.

L1 Cache is the cache that exists per Hibernate session, and this cache is not shared among threads. This cache makes use of Hibernate's own caching.
L2 Cache is a cache that survives beyond a Hibernate session, and can be shared among threads. For this cache you can use either a caching implementation that comes with Hibernate like EHCache or something else like JBossCache2

In JPA/Hibernate (and other similar ORM tools), the L1 cache is the transactional cache i.e. the entities stored from when you open a transaction to when you close it. This is almost never a shared cache (other threads can't make use of it). In JPA, this would usually be held by the EntityManager.
The L2 cache is a full (typically) shared cache. If you have multiple threads/queries pulling in data, then they can make use of entities that have already been retrieved by other threads that are still live in the cache. In JPA, this would usually be held by the EntityManagerFactory.

GaryF is not wrong, but is not technically right :-) Anton is more correct on this, but to complement his answer:
First Level Cache: this is a "cache" which stores all the entities known by a specific session. So, if you have 3 transactions inside this session, it'll hold all entities touched by all three transactions. It gets cleared when you close the session or when you perform the "clear" method.
Second Level Cache: this is a "real" cache and is delegated to an external provider, such as Infinispan. In this cache, you have full control over the contents of the cache, meaning that you are able to specify which entries should be evicted, which ones should be retained longer and so on.

If Hibernate is anything similar to NHibernate (which it is, except the other way round), the Session is the first-level cache. Except that it is not cache in a general sense, but rather an identity map.

L1 By default enabled, you have to add some third party library like EH cache, Redis for L2.
You can't disable L1 in hibernate.

L1:The first-level cache is the cache per Hibernate Session cache and is a mandatory cache through which all requests must pass and this cache is not shared among threads.
L2:The second-level cache can be configured on a per-class and per-collection basis and mainly responsible for caching objects across sessions.L2 Cache is a cache that survives beyond a Hibernate session and can be shared among threads.

As mentioned in this article these are important differences :
First level Cache vs. Second-level Cache in Hibernate Now that we have
got some basic understanding of the first level and second level
cache, here are some differences between them:
The primary difference is that the first level cache is maintained
at the Session level while the second level cache is maintained at the
SessionFactory level.
The data stored in the first level cache is accessible to the only
Session that maintains it, while the second level cache is accessible
to all.
The first level cache is by default enabled while the second level
cache is by default disabled.
A couple of things to know about Hibernate's first level cache:
You can use the Session.evict() to remove the loaded entity from
the first level cache, can use the refresh() method to refresh the
cache, and can use the clear() method to remove all entities in cache.
You cannot disable the first level cache, it is always enabled.
Hibernate entities or database rows remain in cache only until
Session is open, once Session is closed, all associated cached data is
lost.
Read more: https://www.java67.com/2017/10/difference-between-first-level-and-second-level-cache-in-Hibernate.html#ixzz7B8pzzLzL

When does Hibernate read from second-level cache and when from DB?

As far as I know Hibernate let's you configure entities and collections to be stored in a second-level cache.
When does Hibernate try to read these cached entities from the second-level cache and when does it hit the DB? Does Hibernate only read from the second-level cache when loading entities by calling Sesssion.get() and when initializing proxies (including collections)? Does Hibernate ever hit the second-level cache when executing HQL- or Criteria-Queries?
Examples?

2nd level cache contains only entities by their ids, so when retrieving an entity by id (i.e. get, load or resolving a proxy implicitly) a 2nd level cache may be accessed. Any other queries (hal, criteria) will bypass the cache and hit the DB - at least as long as no query cache is used as well.

(Note: the easiest way to answer that type of questions is to turn show_sql on and see what queries Hib generates.)
Sometimes query only return PKs of the records (e.g. for iteration queries) and then Hib can use the cache.
When retrieving linked objects cache can be used too.
I cannot though give you the precise rule here. I also suspect the answer depends on capabilities of dialect used.