HIbernate Inteview Question

🔍 Key Differences Between CrudRepository and JpaRepository

🧠 Summary

Use CrudRepository for basic CRUD operations.
Use JpaRepository when you need pagination, sorting, batch operations, or JPA-specific features.

Since JpaRepository extends CrudRepository, it includes everything CrudRepository offers — and more.

Feature	`CrudRepository`	`JpaRepository`
Inheritance	Base interface for CRUD operations	Extends `CrudRepository`
Basic Methods	`save()`, `findById()`, `delete()`	Inherits all from `CrudRepository`
Additional Features	❌ No extra features	✅ Adds JPA-specific methods
Batch Operations	❌ Not supported	✅ `deleteInBatch()`, `saveAll()`
Pagination & Sorting	❌ Not supported	✅ `findAll(Pageable)`, `findAll(Sort)`
Flush Support	❌ No	✅ `flush()`, `saveAndFlush()`
Use Case	Simple CRUD-only repositories	Advanced JPA features and query customization

🔄 Session vs SessionFactory

🔄 Session vs SessionFactory — Refined Understanding

SessionFactory is like a blueprint or factory that knows how to create sessions. It’s built once when your application starts and holds all the configuration, mappings, and connection settings. Think of it as the central hub that knows how to talk to the database.
Session is the actual conversation between your app and the database. Every time you want to do something — like save a user, fetch a URL mapping, or delete a click event — you open a new session. It’s lightweight, short-lived, and specific to that task or request.

🧠 Analogy Time

Imagine a call center:

SessionFactory is the entire call center setup — the infrastructure, the phone lines, the training manuals.
Session is each individual phone call — a temporary, focused interaction between a customer and an agent.

You don’t rebuild the call center for every call. You just pick up the phone (create a session) when needed.

🔁 Lifecycle Summary

Component	Created When?	Lives How Long?	Used For?
SessionFactory	Once at app startup	Entire app lifecycle	Creating sessions, caching metadata
Session	Per request/transaction	Short-lived (per task)	Performing DB operations

If you're using Spring Boot, it wraps this logic inside EntityManagerFactory and EntityManager, but the core idea remains the same.

🏭 SessionFactory — The Factory

Purpose: Creates Session objects.
Lifecycle: Long-lived; typically one per application.
Thread Safety: Thread-safe and immutable.
Performance: Expensive to create, so it's initialized once at startup.
Responsibilities:
- Loads Hibernate configuration and mappings.
- Manages connection pooling.
- Handles second-level caching.
- Provides access to metadata and services.

🔧 You build it once, and it serves as the backbone for all database interactions.

🚗 Session — The Worker

Purpose: Represents a single unit of work with the database.
Lifecycle: Short-lived; created per transaction or request.
Thread Safety: ❌ Not thread-safe.
Responsibilities:
- Performs CRUD operations (save(), get(), delete(), etc.).
- Manages first-level cache (session-level).
- Handles transaction boundaries.
- Wraps a JDBC connection internally.

🧠 It’s like a temporary workspace where you load, modify, and persist entities.

🔄 Summary Table

Feature	SessionFactory	Session
Scope	Application-wide	Per transaction/request
Thread-safe	Yes	No
Lifecycle	Long-lived	Short-lived
Purpose	Creates Sessions	Performs DB operations
Caching	Second-level cache	First-level cache
Cost to create	High	Low

If you’re using Spring Boot, it often manages these under the hood via EntityManagerFactory, but understanding this distinction helps when debugging or optimizing performance.

🧠 First-Level Cache (Session Cache)

Scope: Tied to a single Hibernate Session
Enabled by default: Yes
Purpose: Prevents repeated database hits for the same entity within one session
Example: If you fetch a User entity twice in the same session, Hibernate will serve the second request from memory, not the database

java

Session session = sessionFactory.openSession();
User user1 = session.get(User.class, 1); // Hits DB
User user2 = session.get(User.class, 1); // Served from cache

🧠 Second-Level Cache (SessionFactory Cache)

Scope: Shared across multiple sessions
Enabled by default: No — you must configure it
Purpose: Stores entities across sessions to reduce DB load for frequently accessed data
Backed by: External cache providers like EHCache, Redis, or Infinispan

// Session 1
Session session1 = sessionFactory.openSession();
User user1 = session1.get(User.class, 1); // Hits DB and stores in 2nd-level cache

// Session 2
Session session2 = sessionFactory.openSession();
User user2 = session2.get(User.class, 1); // Served from 2nd-level cache

🔍 Summary Table

Feature	First-Level Cache	Second-Level Cache
Scope	Per Session	Across Sessions
Enabled by Default	✅ Yes	❌ No (must configure)
Configuration Needed	No	Yes (choose provider + setup)
Use Case	Avoid duplicate DB hits in same session	Improve performance across sessions

Hibernate uses these caching layers to reduce database access, improve response time, and scale better under load. If you're building a high-performance app, configuring second-level caching can be a game-changer.

Want help setting up EHCache or Redis for second-level caching in your project?

🧠 First-Level Cache (Session Cache)

Scope: Tied to a single Hibernate Session
Enabled by default: Yes
Purpose: Prevents repeated database hits for the same entity within one session
Example: If you fetch a User entity twice in the same session, Hibernate will serve the second request from memory, not the database.

🧠 Second-Level Cache (SessionFactory Cache)

Scope: Shared across multiple sessions
Enabled by default: No — you must configure it
Purpose: Stores entities across sessions to reduce DB load for frequently accessed data
Backed by: External cache providers like EHCache, Redis, or Infinispan.

How does hibernate manage transaction?

Hibernate manages transactions using its own Transaction API, which wraps around JDBC or JTA (Java Transaction API) depending on your setup. The goal is to ensure that a group of database operations either fully succeed or fully fail—preserving data integrity through the ACID principles: Atomicity, Consistency, Isolation, and Durability.

🔧 Two Ways Hibernate Manages Transactions

1. Programmatic Transaction Management

You manually control the transaction lifecycle in your code:

Transaction transaction = null;

try (Session session = sessionFactory.openSession()) {

transaction = session.beginTransaction();

// Perform DB operations

session.save(entity);

transaction.commit(); // All good

} catch (Exception e) {

if (transaction != null) transaction.rollback(); // ❌ Rollback on error

e.printStackTrace();

}

You explicitly begin, commit, and rollback transactions.

Gives you fine-grained control, but can be verbose and error-prone.

2. Declarative Transaction Management (Spring + Hibernate)

You let Spring handle it using annotations:

@Transactional

public void saveUser(User user) {

userRepository.save(user);

}

Spring opens and commits the transaction automatically.

If an exception occurs, it rolls back the transaction.

Cleaner and easier to maintain.

What is the Criteria API in Hibernate?

🔧 Real-World Example

Imagine a job portal where users can filter jobs by location, salary, experience, and company. Instead of writing dozens of static queries, you use Criteria API to build one dynamic query that adapts to whatever filters the user selects.

Where Do We Use Criteria API?

Search Filters in Web Apps For example, filtering users by name, age, or location based on user input.
Admin Dashboards When building dynamic reports or analytics with multiple optional filters.
Multi-Field Search Forms Criteria API shines when you don’t know in advance which fields will be used for filtering.
Complex Business Logic Queries When queries involve multiple joins, conditions, or aggregations.
Reusable Query Components You can modularize query logic and reuse it across services or repositories.

Let’s build a real-world example using the Criteria API based on your project context. Suppose you have a User entity and you want to search users dynamically based on optional filters like:

First name
Email
Role

Here’s how you can do it using Hibernate’s JPA Criteria API:

🛠️ Sample Criteria Query

public List<User> searchUsers(String firstName, String email, String role) {

Session session = sessionFactory.openSession();

CriteriaBuilder cb = session.getCriteriaBuilder();

CriteriaQuery<User> query = cb.createQuery(User.class);

Root<User> root = query.from(User.class);

List<Predicate> predicates = new ArrayList<>();

if (firstName != null && !firstName.isEmpty()) {

predicates.add(cb.equal(root.get("firstName"), firstName));

}

if (email != null && !email.isEmpty()) {

predicates.add(cb.equal(root.get("email"), email));

}

if (role != null && !role.isEmpty()) {

predicates.add(cb.equal(root.get("role"), role));

}

query.select(root).where(cb.and(predicates.toArray(new Predicate[0])));

return session.createQuery(query).getResultList();

}

🔍 What’s Happening Here

We use CriteriaBuilder to start building the query.
Root<User> defines the entity/table we’re querying.
We dynamically add Predicates based on which filters are provided.
The final query is executed with all active conditions.

🧠 Why This Is Useful

You don’t need to write multiple query methods for different combinations of filters.
It’s safe, clean, and easy to extend (e.g., add pagination, sorting, etc.).

Q8. Explain the concept of Object States in Hibernate.

In Hibernate, objects can exist in one of three states: transient (not associated with any session), persistent (associated with a session), and detached (was once associated with a session but then got detached).

Yesterday

[classes/:na] Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'dataSourceScriptDatabaseInitializer' defined in class path resource [org/springframework/boot/autoconfigure/sql/init/DataSourceInitializationConfiguration.class]: Unsatisfied dependency expressed through method 'dataSourceScriptDatabaseInitializer' parameter 0: Error creating bean with name 'dataSource' defined in class path resource [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]: Failed to instantiate [com.zaxxer.hikari.HikariDataSource]: Factory method 'dataSource' threw exception with message: Cannot load driver class: com.mysql.cj.jdbc.Driver at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:804) ~[spring-beans-6.2.10.jar:6.2.10] at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:546) ~[spring-beans-6.2.10.jar:6.2.

This error is a classic Spring Boot startup failure caused by a missing or misconfigured MySQL JDBC driver. Let's break it down and walk through how to fix it:

🧩 Root Cause

The key part of the error is:

Code

Cannot load driver class: com.mysql.cj.jdbc.Driver

This means Spring Boot is trying to initialize a MySQL datasource using HikariCP, but it can't find the MySQL driver class in the classpath.

🛠️ How to Fix It

1. Add MySQL JDBC Driver Dependency

If you're using Maven, make sure your pom.xml includes:

xml

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.33</version> <!-- Use latest stable version -->
</dependency>

If you're using Gradle:

groovy

implementation 'mysql:mysql-connector-java:8.0.33'

2. Check Your `application.properties` or `application.yml`

Make sure your datasource configuration is correct:

properties

spring.datasource.url=jdbc:mysql://localhost:3306/your_database
spring.datasource.username=your_username
spring.datasource.password=your_password
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

Or in YAML:

yaml

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/your_database
    username: your_username
    password: your_password
    driver-class-name: com.mysql.cj.jdbc.Driver

3. Ensure the Driver Is in the Classpath

If you're running the app outside your IDE (e.g., via java -jar), make sure the MySQL driver is bundled in your final JAR or available in the classpath.

4. Clean and Rebuild

Sometimes stale builds cause issues. Run:

bash

mvn clean install

Or for Gradle:

bash

./gradlew clean build

Want help checking your full config or build file? Just paste it here and I’ll walk through it with you.

Spring Boot MySQL error

chatgpt.com

... 79 common frames omitted Caused by: org.hibernate.AnnotationException: Property 'com.example.url_shortener.Entity.UrlMapping.user' is a '@ManyToMany' and is directly annotated '@JoinColumn' (specify '@JoinColumn' inside '@JoinTable' or '

Ah, this is a classic Hibernate mapping misstep. The error you're seeing:

Code

Property 'com.example.url_shortener.Entity.UrlMapping.user' is a '@ManyToMany' and is directly annotated '@JoinColumn'

means Hibernate is confused because you're trying to use @JoinColumn directly on a @ManyToMany relationship—which isn't allowed. Let’s break it down and fix it.

🧠 Why This Happens

In JPA/Hibernate, a @ManyToMany relationship must use a @JoinTable, not a @JoinColumn. That’s because many-to-many associations require an intermediate join table to map the relationship.

✅ How to Fix It

Let’s say your entity looks like this:

java

@ManyToMany
@JoinColumn(name = "user_id") // ❌ This is invalid
private List<User> users;

You need to replace it with:

java

@ManyToMany
@JoinTable(
    name = "urlmapping_user", // name of the join table
    joinColumns = @JoinColumn(name = "urlmapping_id"), // FK to current entity
    inverseJoinColumns = @JoinColumn(name = "user_id") // FK to target entity
)
private List<User> users;

This tells Hibernate:

Use a join table named urlmapping_user
Link urlmapping_id to your current entity (UrlMapping)
Link user_id to the User entity

🔍 Bonus Tip

If you want to customize the join table name or column names, this is the place to do it. Otherwise, Hibernate will auto-generate names that might not match your DB schema.

If you share your full UrlMapping entity, I can help you rewrite the annotations precisely. Want to do that?

Spring Boot MySQL error

chatgpt.com

Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]: Association 'com.example.url_shortener.Entity.UrlMapping.clickEvents' targets the type 'com.example.url_shortener.Entity.ClickEvent' which is not an '

This error is pointing to a problem in your JPA entity mapping—specifically with the clickEvents association in your UrlMapping entity. The key part is:

Code

Association 'com.example.url_shortener.Entity.UrlMapping.clickEvents' targets the type 'com.example.url_shortener.Entity.ClickEvent' which is not an ...

That unfinished message usually ends with something like “...which is not an entity” or “...which is not annotated with @Entity.”

🧠 What This Means

Hibernate is trying to map a relationship to ClickEvent, but it doesn’t recognize ClickEvent as a valid JPA entity. This typically happens when:

The ClickEvent class is missing the @Entity annotation.
The class is not in a package that’s scanned by Spring Boot.
There’s a typo or mismatch in the class name or import.

✅ How to Fix It

Here’s what to check:

1. Annotate `ClickEvent` Properly

Make sure your ClickEvent class looks like this:

java

package com.example.url_shortener.Entity;

import jakarta.persistence.Entity;
import jakarta.persistence.Id;

@Entity
public class ClickEvent {
    @Id
    private Long id;

    // other fields and mappings
}

⚠️ If you're using Spring Boot 3.x+, make sure you're using jakarta.persistence.* imports, not javax.persistence.*.

2. Ensure It’s in a Scanned Package

Spring Boot automatically scans entities in the same package or sub-packages of your main application class. If ClickEvent is outside that scope, either move it or explicitly scan it:

java

@SpringBootApplication
@EntityScan(basePackages = "com.example.url_shortener.Entity")
public class Application { ... }

3. Check Your Relationship Mapping

In UrlMapping, make sure the relationship is valid:

java

@OneToMany(mappedBy = "urlMapping")
private List<ClickEvent> clickEvents;

And in ClickEvent, you should have:

java

@ManyToOne
@JoinColumn(name = "url_mapping_id")
private UrlMapping urlMapping;

If you want to paste your entity classes here, I can help you fine-tune the annotations. Want to do that?

Spring Boot MySQL error

chatgpt.com

package com.example.url_shortener.Entity; import jakarta.persistence.*; import lombok.Data; @Entity @Data @Table(name = "users") public class User { @Id

Thanks for sharing the start of your User entity. Based on the context and the error you're facing with the UrlMapping.clickEvents association, it looks like your project is encountering multiple JPA mapping issues. Let's tackle them one by one.

✅ Fixing the `ClickEvent` Entity Issue

From the error:

Code

Association 'com.example.url_shortener.Entity.UrlMapping.clickEvents' targets the type 'ClickEvent' which is not an ...

This typically means ClickEvent is either:

Missing the @Entity annotation
Not properly imported or scanned by Spring Boot

Make sure your ClickEvent class looks like this:

java

package com.example.url_shortener.Entity;

import jakarta.persistence.*;
import lombok.Data;

@Entity
@Data
@Table(name = "click_events")
public class ClickEvent {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    // Example fields
    private String ipAddress;
    private String userAgent;

    @ManyToOne
    @JoinColumn(name = "url_mapping_id")
    private UrlMapping urlMapping;
}

🔗 Mapping `clickEvents` in `UrlMapping`

In your UrlMapping entity, the relationship should be:

java

@OneToMany(mappedBy = "urlMapping", cascade = CascadeType.ALL, orphanRemoval = true)
private List<ClickEvent> clickEvents;

This ensures Hibernate knows how to link the two entities.

🧠 Entity Scan Reminder

If your entities are in a package that’s not automatically scanned by Spring Boot, add this to your main class:

java

@SpringBootApplication
@EntityScan(basePackages = "com.example.url_shortener.Entity")
public class UrlShortenerApplication { ... }

Would you like help reviewing the full UrlMapping entity or your pom.xml to ensure everything’s wired correctly? I can walk through it with you.

Today

what is session factory in hibernate

Great question, Shivam! The SessionFactory is one of the most important components in Hibernate—it’s the heavyweight backbone of the framework’s database interaction layer.

🏗️ What Is SessionFactory?

In Hibernate, the SessionFactory is a thread-safe, immutable, and heavyweight object that acts as a factory for Session instances. It’s designed to be created once per application (or per database) and reused throughout the lifecycle of the app.

🔧 Key Responsibilities

Creates Session objects: These are lightweight, short-lived objects used to interact with the database.
Manages database connections: It handles connection pooling and transaction management.
Caches metadata: It stores mappings between Java classes and database tables, improving performance.
Supports second-level caching: This helps reduce database hits by caching entities across sessions.

🧪 Typical Usage

java

Configuration configuration = new Configuration().configure();
SessionFactory sessionFactory = configuration.buildSessionFactory();
Session session = sessionFactory.openSession();

Once you have a Session, you can perform operations like:

java

session.save(entity);
session.get(Entity.class, id);
session.close();

🧠 Why It Matters

Efficiency: Creating a SessionFactory is expensive, so it should be done once and reused.
Scalability: It’s designed to handle concurrent access in multi-threaded environments.
Centralized Configuration: It encapsulates all Hibernate settings and mappings.

If you're using Spring Boot with Hibernate, the SessionFactory is usually managed automatically via Spring’s configuration. But understanding its role helps you appreciate how Hibernate works under the hood.

Want to see how to configure it manually or integrate it with Spring Boot? I can walk you through that too.

Can you explain the difference between Session and SessionFactory?

Absolutely, Shivam! Think of SessionFactory and Session in Hibernate like a car manufacturing plant and the cars it produces. Here's how they differ:

🏭 SessionFactory — The Factory

Purpose: Creates Session objects.
Lifecycle: Long-lived; typically one per application.
Thread Safety: ✅ Thread-safe and immutable.
Performance: Expensive to create, so it's initialized once at startup.
Responsibilities:
- Loads Hibernate configuration and mappings.
- Manages connection pooling.
- Handles second-level caching.
- Provides access to metadata and services.

🔧 You build it once, and it serves as the backbone for all database interactions.

🚗 Session — The Worker

Purpose: Represents a single unit of work with the database.
Lifecycle: Short-lived; created per transaction or request.
Thread Safety: ❌ Not thread-safe.
Responsibilities:
- Performs CRUD operations (save(), get(), delete(), etc.).
- Manages first-level cache (session-level).
- Handles transaction boundaries.
- Wraps a JDBC connection internally.

🧠 It’s like a temporary workspace where you load, modify, and persist entities.

🔄 Summary Table

Feature	SessionFactory	Session
Scope	Application-wide	Per transaction/request
Thread-safe	Yes	No
Lifecycle	Long-lived	Short-lived
Purpose	Creates Sessions	Performs DB operations
Caching	Second-level cache	First-level cache
Cost to create	High	Low

If you’re using Spring Boot, it often manages these under the hood via EntityManagerFactory, but understanding this distinction helps when debugging or optimizing performance.

Want to dive into how transactions behave across sessions next?

1st level and second level ache means

Great question, Shivam! In Hibernate, caching is a powerful performance optimization technique, and it’s divided into first-level and second-level caches. Here's how they differ:

🧠 First-Level Cache (Session Cache)

Scope: Tied to a single Hibernate Session
Enabled by default: Yes
Purpose: Prevents repeated database hits for the same entity within one session
Example: If you fetch a User entity twice in the same session, Hibernate will serve the second request from memory, not the database

java

Session session = sessionFactory.openSession();
User user1 = session.get(User.class, 1); // Hits DB
User user2 = session.get(User.class, 1); // Served from cache

🧠 Second-Level Cache (SessionFactory Cache)

Scope: Shared across multiple sessions
Enabled by default: No — you must configure it
Purpose: Stores entities across sessions to reduce DB load for frequently accessed data
Backed by: External cache providers like EHCache, Redis, or Infinispan

java

// Session 1
Session session1 = sessionFactory.openSession();
User user1 = session1.get(User.class, 1); // Hits DB and stores in 2nd-level cache

// Session 2
Session session2 = sessionFactory.openSession();
User user2 = session2.get(User.class, 1); // Served from 2nd-level cache

🔍 Summary Table

Feature	First-Level Cache	Second-Level Cache
Scope	Per Session	Across Sessions
Enabled by Default	✅ Yes	❌ No (must configure)
Configuration Needed	No	Yes (choose provider + setup)
Use Case	Avoid duplicate DB hits in same session	Improve performance across sessions

Want help setting up EHCache or Redis for second-level caching in your project?

you are sayinh ki session is used to create session between object and db per request but in session factory it used to create session object and create only once per application

Exactly, Shivam — you've got the essence right, and let me sharpen it a bit more for clarity.

🔄 Session vs SessionFactory — Refined Understanding

SessionFactory is like a blueprint or factory that knows how to create sessions. It’s built once when your application starts and holds all the configuration, mappings, and connection settings. Think of it as the central hub that knows how to talk to the database.
Session is the actual conversation between your app and the database. Every time you want to do something — like save a user, fetch a URL mapping, or delete a click event — you open a new session. It’s lightweight, short-lived, and specific to that task or request.

🧠 Analogy Time

Imagine a call center:

SessionFactory is the entire call center setup — the infrastructure, the phone lines, the training manuals.
Session is each individual phone call — a temporary, focused interaction between a customer and an agent.

You don’t rebuild the call center for every call. You just pick up the phone (create a session) when needed.

🔁 Lifecycle Summary

Component	Created When?	Lives How Long?	Used For?
SessionFactory	Once at app startup	Entire app lifecycle	Creating sessions, caching metadata
Session	Per request/transaction	Short-lived (per task)	Performing DB operations

If you're using Spring Boot, it wraps this logic inside EntityManagerFactory and EntityManager, but the core idea remains the same.

Want to see how this plays out in a real Hibernate config or Spring Boot setup? I can show you both.

how does hibernate manage transaction ?

🔧 Two Ways Hibernate Manages Transactions

1. Programmatic Transaction Management

You manually control the transaction lifecycle in your code:

java

Transaction transaction = null;
try (Session session = sessionFactory.openSession()) {
    transaction = session.beginTransaction();

    // Perform DB operations
    session.save(entity);

    transaction.commit(); // ✅ All good
} catch (Exception e) {
    if (transaction != null) transaction.rollback(); // ❌ Rollback on error
    e.printStackTrace();
}

You explicitly begin, commit, and rollback transactions.
Gives you fine-grained control, but can be verbose and error-prone.

2. Declarative Transaction Management (Spring + Hibernate)

You let Spring handle it using annotations:

java

@Transactional
public void saveUser(User user) {
    userRepository.save(user);
}

Spring opens and commits the transaction automatically.
If an exception occurs, it rolls back the transaction.
Cleaner and easier to maintain.

🧠 Key Concepts

Concept	Description
`Session`	Represents a single unit of work and wraps a JDBC connection.
`Transaction`	Represents a single transaction. You begin, commit, or rollback using this.
`@Transactional`	Spring annotation to manage transactions declaratively.
Rollback	Ensures no partial changes are saved if something fails.

Hibernate integrates seamlessly with Spring Boot, so most modern apps use declarative management. But knowing both styles helps when debugging or optimizing performance.

Want to see how this works with nested transactions or exception handling? I can walk you through that next.

what is criteria Api in hibernate ?

The Criteria API in Hibernate is a powerful, object-oriented way to build dynamic queries without writing raw SQL or HQL. Instead of writing query strings, you construct queries using Java objects and methods—making your code more type-safe, readable, and maintainable.

🧠 What It Does

Allows you to build queries programmatically using Java.
Supports dynamic filtering, sorting, pagination, and joins.
Helps avoid SQL injection by using parameterized queries.
Works well when query conditions are not known at compile time.

🛠️ Example Using JPA Criteria API (Hibernate 5.2+)

java

Session session = sessionFactory.openSession();
CriteriaBuilder cb = session.getCriteriaBuilder();
CriteriaQuery<User> query = cb.createQuery(User.class);
Root<User> root = query.from(User.class);

// Add conditions
query.select(root).where(cb.equal(root.get("firstName"), "Shivam"));

List<User> results = session.createQuery(query).getResultList();

This builds a query like:

sql

SELECT * FROM users WHERE first_name = 'Shivam';

🔍 Key Components

Component	Role
`CriteriaBuilder`	Entry point to build queries
`CriteriaQuery`	Represents the query structure
`Root<T>`	Defines the entity/table to query
`Predicate`	Represents conditions (WHERE clauses)

🧨 Deprecated Hibernate Criteria API

Hibernate used to have its own Criteria API (pre-5.2), like:

java

Criteria criteria = session.createCriteria(User.class);
criteria.add(Restrictions.eq("firstName", "Shivam"));
List<User> users = criteria.list();

But this is now deprecated, and the JPA Criteria API is the recommended approach.

If you're building complex queries with multiple filters, joins, or dynamic conditions, Criteria API is your best friend. Want help writing a Criteria query for your own entity? Just share the structure and I’ll whip one up.

benefit oof using this and where we use this

The Criteria API in Hibernate is a game-changer when it comes to writing flexible, dynamic, and type-safe queries. Here's a breakdown of its benefits and where it's most useful:

🎯 Benefits of Using Criteria API

✅ Type-Safe Queries You build queries using Java objects and methods, which means compile-time checking and fewer runtime errors.
🛡️ Protection Against SQL Injection Since it uses parameterized queries under the hood, it’s much safer than string-based query construction.
🔄 Dynamic Query Building You can construct queries based on runtime conditions—perfect for search filters or user-driven queries.
🧩 Object-Oriented Syntax No need to write raw SQL or HQL. You use Java constructs like CriteriaBuilder, Predicate, and Root.
📦 Integration with JPA Works seamlessly with JPA and Hibernate, especially in Spring Boot applications.
🔍 Supports Complex Queries You can easily add joins, groupings, projections, and nested conditions.

🧠 Where Do We Use Criteria API?

Search Filters in Web Apps For example, filtering users by name, age, or location based on user input.
Admin Dashboards When building dynamic reports or analytics with multiple optional filters.
Multi-Field Search Forms Criteria API shines when you don’t know in advance which fields will be used for filtering.
Complex Business Logic Queries When queries involve multiple joins, conditions, or aggregations.
Reusable Query Components You can modularize query logic and reuse it across services or repositories.

🔧 Real-World Example

If you want, I can show you how to write a Criteria query for one of your entities—just tell me which one and what filters you want to apply.

yes

Awesome, Shivam! Let’s build a real-world example using the Criteria API based on your project context. Suppose you have a User entity and you want to search users dynamically based on optional filters like:

First name
Email
Role

Here’s how you can do it using Hibernate’s JPA Criteria API:

🛠️ Sample Criteria Query

java

public List<User> searchUsers(String firstName, String email, String role) {
    Session session = sessionFactory.openSession();
    CriteriaBuilder cb = session.getCriteriaBuilder();
    CriteriaQuery<User> query = cb.createQuery(User.class);
    Root<User> root = query.from(User.class);

    List<Predicate> predicates = new ArrayList<>();

    if (firstName != null && !firstName.isEmpty()) {
        predicates.add(cb.equal(root.get("firstName"), firstName));
    }

    if (email != null && !email.isEmpty()) {
        predicates.add(cb.equal(root.get("email"), email));
    }

    if (role != null && !role.isEmpty()) {
        predicates.add(cb.equal(root.get("role"), role));
    }

    query.select(root).where(cb.and(predicates.toArray(new Predicate[0])));

    return session.createQuery(query).getResultList();
}

🔍 What’s Happening Here

We use CriteriaBuilder to start building the query.
Root<User> defines the entity/table we’re querying.
We dynamically add Predicates based on which filters are provided.
The final query is executed with all active conditions.

🧠 Why This Is Useful

You don’t need to write multiple query methods for different combinations of filters.
It’s safe, clean, and easy to extend (e.g., add pagination, sorting, etc.).
Works beautifully in search forms, admin panels, and reporting dashboards.

Want to try building a Criteria query for your UrlMapping or ClickEvent entity next? Just tell me what filters or conditions you want to apply.

Explain the concept of Object States in Hibernate.

Hibernate defines three primary object states that represent the lifecycle of an entity in relation to the database and the Hibernate Session. Understanding these states helps you manage persistence and optimize performance.

🔄 1. Transient State

Definition: The object is created using new, but it’s not associated with any Hibernate Session.
Database Link: ❌ No representation in the database.
Persistence Context: Not tracked by Hibernate.
Example:

java

User user = new User(); // Transient
user.setName("Shivam");

Changes to this object won’t be saved unless it’s explicitly persisted.

🔄 2. Persistent State

Definition: The object is associated with an open Hibernate Session.
Database Link: ✅ Represents a row in the database.
Persistence Context: Tracked by Hibernate. Any changes are automatically synchronized with the DB.
Example:

java

Session session = sessionFactory.openSession();
session.beginTransaction();
session.save(user); // Now persistent
session.getTransaction().commit();

Hibernate automatically detects changes and updates the database when the transaction is committed.

🔄 3. Detached State

Definition: The object was once associated with a session, but the session is now closed.
Database Link: ✅ Still represents a row in the database.
Persistence Context: ❌ No longer tracked by Hibernate.
Example:

java

session.close(); // user becomes detached
user.setName("Updated Shivam"); // Change won't be tracked

You need to reattach it using session.update() or session.merge() to persist changes.

🧠 Bonus: Removed State (Optional)

Some sources also mention a removed state, where an entity is scheduled for deletion but not yet removed from the database until the transaction is committed.

📊 Summary Table

State	Associated with Session	Stored in DB	Tracked by Hibernate
Transient	❌ No	❌ No	❌ No
Persistent	✅ Yes	✅ Yes	✅ Yes
Detached	❌ No (was Yes)	✅ Yes	❌ No

Understanding these states helps you avoid common pitfalls like lazy loading exceptions, unintended updates, or memory leaks. Want to see how these states behave in a real Hibernate transaction flow? I can walk you through that next.

so what is use of transaient persistent and detached where we can use how can i decide

Understanding when and how to use transient, persistent, and detached states in Hibernate is key to writing efficient, predictable, and bug-free data access code. Let’s break it down with real-world use cases and decision points:

🚦 1. Transient State

Use When: You’re creating a new object that hasn’t been saved to the database yet.

Typical Scenario:

You instantiate a new entity using new.
You want to populate its fields before saving.

Example:

java

User user = new User(); // Transient
user.setName("Shivam");

Decision Point: Use transient when you're preparing data but haven't yet decided to persist it. Once ready, pass it to a session to make it persistent.

🔄 2. Persistent State

Use When: You want Hibernate to track changes and automatically sync them with the database.

Typical Scenario:

You save a new entity using session.save() or session.persist().
You load an entity using session.get() or session.load().

Example:

java

Session session = sessionFactory.openSession();
session.beginTransaction();
session.save(user); // Now persistent
user.setEmail("shivam@example.com"); // Hibernate tracks this change
session.getTransaction().commit();

Decision Point: Use persistent state when you want automatic change tracking and database synchronization. This is ideal during active transactions.

🔌 3. Detached State

Use When: You need to work with an entity outside of a session (e.g., in a web layer or after session is closed).

Typical Scenario:

You fetch an entity, close the session, and pass it to another layer.
You later reattach it to a new session to update or delete.

Example:

java

session.close(); // user becomes detached
user.setName("Updated Shivam"); // Change not tracked
Session newSession = sessionFactory.openSession();
newSession.update(user); // Reattach and persist changes

Decision Point: Use detached state when you need to pass entities across layers (e.g., from DAO to service to controller) and reattach them later for updates.

🧠 Summary Table

State	When to Use	Hibernate Tracks Changes	Needs Session
Transient	Before saving to DB	❌ No	❌ No
Persistent	During active DB operations	✅ Yes	✅ Yes
Detached	After session is closed, for reuse	❌ No (until reattached)	❌ No

💡 How to Decide?

Ask yourself:

Do I need to save this object? → Start with transient.
Am I in a transaction and want Hibernate to track changes? → Make it persistent.
Do I need to pass this object outside the session and update later? → It will become detached.

Hibernate’s lifecycle is like managing relationships: transient is like dating, persistent is like marriage, and detached is like a long-distance relationship—you can reconnect, but you need effort 😄

Want to see how this plays out in a Spring Boot service layer or with REST APIs? I can show you that next.

means you are saying we use persiste to commit data in db automatically , for detaches state it come in picture after session expire and for transaient we want tnot to commit in db

🔄 Hibernate Object States — Refined Summary

🟡 Transient

What it is: A newly created object using new, not yet associated with Hibernate.
Use case: You’re preparing data but haven’t decided to save it yet.
DB impact: ❌ Not saved to the database.

User user = new User(); // Transient

user.setName("Ram Ji");

🟢 Persistent

What it is: An object that’s attached to an active Hibernate Session.
Use case: You want Hibernate to track changes and commit them automatically.
DB impact: ✅ Changes are synced with the database on commit().
Example:

session.save(user); // Becomes persistent

user.setEmail("Ramji@example.com"); // Hibernate tracks this

session.getTransaction().commit(); // Changes saved

🔵 Detached

What it is: An object that was persistent but the session is now closed.
Use case: You want to reuse or update the object later.
DB impact: ❌ Changes are not tracked unless reattached.
Example:

session.close(); // user becomes detached

user.setName("Updated Shivam"); // Not tracked

newSession.update(user); // Reattach and persist changes

🧠 Decision Guide

Goal	Use This State
Prepare data but not save	Transient
Save and auto-track changes	Persistent
Reuse/update after session	Detached

What is the purpose of the Configuration class in Hibernate?

The Configuration class in Hibernate is used to configure settings from hibernate.cfg.xml file. It bootstraps the Hibernate and allows the application to specify properties and mapping documents to be used when creating a SessionFactory.

🧠 Purpose of the `Configuration` Class

The Configuration class is used to:

Load Hibernate settings from configuration files like hibernate.cfg.xml or hibernate.properties.
Register entity classes and mapping files (either annotated classes or XML-based .hbm.xml files).
Set up database connection properties such as URL, username, password, dialect, driver class, etc.
Build the SessionFactory, which is the core object used to create sessions and perform database operations.

📦 What It Bootstraps

Component	Role
`hibernate.cfg.xml`	Contains DB and Hibernate settings
Entity mappings	Defines how Java classes map to DB tables
`SessionFactory`	Created using `Configuration` to manage sessions

software development, bootstrapping (or "bootstrap") refers to the process of starting up a system or application from scratch—often with minimal initial resources. It’s like pulling yourself up by your own bootstraps: using a small, simple foundation to build something much larger and more complex.

🧠 In Contexts Like Hibernate or Spring

When we say Hibernate “bootstraps” itself using the Configuration class, we mean:

It loads configuration files (like hibernate.cfg.xml)
It registers entity mappings
It initializes the SessionFactory, which is the core engine for database operations

So, bootstrapping here means setting up the entire Hibernate infrastructure so your app can start interacting with the database.

Q11. What are the differences between get() and load() methods in Hibernate?

The get() method in Hibernate retrieves the object if it exists in the database; otherwise, it returns null. The load() method also retrieves the object, but if it doesn’t exist, it throws an ObjectNotFoundException. load() can use a proxy to fetch the data lazily.

🔍 Key Differences Between `get()` and `load()` in Hibernate

Feature	`get()` Method	`load()` Method
Loading Strategy	Eager loading — hits the DB immediately	Lazy loading — returns a proxy object
Return Type	Actual entity object	Proxy object (placeholder)
If Entity Not Found	Returns `null`	Throws `ObjectNotFoundException`
Performance	Slightly slower (loads full object)	Faster (defers loading until needed)
Use Case	Use when you're unsure if the entity exists	Use when you're sure the entity exists

How does Hibernate ensure data integrity?

🔐 1. Transaction Management

Hibernate wraps all database operations in transactions using its Transaction API or Spring’s @Transactional annotation.

If any operation fails, Hibernate rolls back the entire transaction.
This prevents partial updates and ensures atomicity—either all changes succeed, or none do.

Example: If you're saving a User and their associated ClickEvent, and the ClickEvent fails, the User won't be saved either.

🧠 2. Dirty Checking

Hibernate automatically tracks changes to persistent entities during a session.

It compares the current state of an object with its original state (snapshot).
Only modified fields are updated in the database.
This avoids accidental overwrites and ensures accurate updates.

🧱 3. Constraint Enforcement

Hibernate respects and enforces database-level constraints like:

Primary keys
Foreign keys
Unique constraints
Not-null constraints

If you try to violate these (e.g., insert a null into a non-null column), Hibernate throws a DataIntegrityViolationException.

🔄 4. Optimistic & Pessimistic Locking

To handle concurrent access:

Optimistic locking uses a @Version field to detect conflicting updates.
Pessimistic locking locks rows during a transaction to prevent other sessions from modifying them.

This ensures consistency when multiple users access the same data.

🧪 5. Validation & Cascading

Hibernate integrates with Bean Validation (JSR 380) to validate entity fields before persisting.
Cascade operations ensure related entities are updated or deleted together, maintaining relational integrity.

🧠 Real-World Scenario

Imagine you're updating a user's profile and their associated settings. Hibernate:

Starts a transaction
Tracks changes via dirty checking
Validates fields
Updates both entities atomically
Rolls back if anything fails

Result: Your database stays clean, consistent, and trustworthy.

🔐 1. Optimistic Locking — Preventing Conflicting Updates

Hibernate uses a special field annotated with @Version to track changes and prevent concurrent modification issues.

✅ How to Use It

@Entity

public class User {

@Id

private Long id;

private String name;

@Version

private int version; // Hibernate auto-manages this

}

🧠 What Happens

When you load a User, Hibernate stores its version.
When you update it, Hibernate checks if the version in DB matches.
If someone else updated it in the meantime, the versions mismatch → Hibernate throws OptimisticLockException.

This ensures no two sessions overwrite each other’s changes silently.

Now imagine this flow:

You load a user with version = 3.
You update the name: user.setName("Shivam Updated").
You commit the transaction.

Hibernate will:

Check that the current version in the DB is still 3.
If it matches, it updates the record and sets version = 4.

✅ This ensures that no other transaction has modified the entity in the meantime.

🧠 Why This Matters

It prevents lost updates in concurrent environments.
It allows Hibernate to detect stale data and throw an exception if needed.
It’s automatic — you don’t need to manually increment the version.

🔍 2. Dirty Checking — Tracking Changes Automatically

Hibernate keeps a snapshot of each persistent entity when it’s loaded. If you modify a field, Hibernate detects the change and updates the DB automatically on commit().

✅ Example

Session session = sessionFactory.openSession();

session.beginTransaction();

User user = session. Get(User. Class, 1); // Persistent

user.setName("Updated Shivam"); // Hibernate tracks this change

session.getTransaction(). commit(); // Auto-updates DB

. How can you achieve concurrency in Hibernate?

To achieve concurrency in Hibernate—meaning multiple users or threads can safely access and modify data at the same time—you need to combine smart transaction handling with proper locking strategies. Hibernate offers two main approaches: optimistic locking and pessimistic locking, plus support for transaction isolation levels.

🔐 1. Optimistic Locking (Default in Hibernate)

How it works: Each entity has a @Version field. When an update happens, Hibernate checks if the version in memory matches the version in the database.
If mismatch: Hibernate throws an OptimisticLockException to prevent overwriting newer data.
Best for: Low-conflict environments (e.g., read-heavy apps).

@Version
private int version;

This allows multiple users to read the same data,

but only one can successfully update it if no one else has changed it in the meantime.

.
🔒 2. Pessimistic Locking
How it works: Hibernate locks the database row during a transaction using SQL SELECT FOR UPDATE.
Prevents: Other transactions from reading or writing the locked row.
Best for: High-conflict environments (e.g., financial apps, inventory systems).

🔄 3. Transaction Isolation Levels

Hibernate respects the isolation level defined by your database (e.g., READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE).
These control how visible changes are across concurrent transactions.

For example, REPEATABLE_READ ensures that if you read a row twice in the same transaction,

it won’t change—even if another transaction modifies it in between.

🔐 Optimistic Locking — Trust First, Verify Later
No actual DB row lock during read or write.
Hibernate relies on a @Version field to detect if someone else modified the data.
If the version matches → ✅ update proceeds.
If the version changed → ❌ throws OptimisticLockException.

🔒 Pessimistic Locking — Lock First, Then Work

Hibernate issues a SQL SELECT FOR UPDATE when reading the row.
This locks the row in the database.
Other transactions must wait until your transaction completes.
Ensures no one else can read or write to that row during your operation.

❓ Q: Your Hibernate app is slow when fetching data with many relationships. What strategy would you use?

Answer: I’d use lazy loading to avoid fetching unnecessary related entities upfront.

To fix N+1 query issues, I’d apply join fetching, batch fetching, or subselect fetching.

Additionally, I’d use DTO projections for read-only views and enable second-level caching for frequently accessed data.

1. Use Lazy Loading Wisely

Set relationships to FetchType.LAZY instead of EAGER.
This ensures related entities are loaded only when accessed, not upfront.

@OneToMany(fetch = FetchType.LAZY, mappedBy = "user")

private List<Order> orders;

Lazy loading reduces unnecessary data fetching and memory usage.

2. Avoid the N+1 SELECT Problem

Happens when Hibernate fetches one parent entity and then makes N additional queries for each child.
Fix it using:

JOIN FETCH in JPQL
@EntityGraph or @NamedEntityGraph
Batch fetching (hibernate.default_batch_fetch_size).

@Query("SELECT u FROM User u JOIN FETCH u.orders")

List<User> findAllWithOrders();

This pulls parent and child data in a single query, drastically reducing DB hits

3. Enable Batch Fetching

Configure in application.properties:

spring.jpa.properties.hibernate.default_batch_fetch_size=16

Hibernate will group lazy loads into batches, reducing round trips.

4 Use DTO Projections for Read-Only Views

Instead of loading full entities, fetch only required fields into DTOs.

@Query("SELECT new com.example.UserDTO(u.id, u.name) FROM User u")

List<UserDTO> findAllUsers();

This avoids loading unnecessary relationships and improves query speed.

❓ Q: How do you manage Hibernate sessions in a web app to prevent memory leaks?

Answer: I use the Session-per-request strategy, where a Hibernate session is opened at the start of each HTTP request and closed at the end. This ensures that sessions are short-lived and properly cleaned up. In a Spring-based application, this is typically handled automatically using @Transactional, which binds the session to the current thread and closes it after the transaction completes. For manual setups, I ensure sessions are closed in a finally block or use try-with-resources to guarantee cleanup.

❓ Q: What happens if an error occurs during a Hibernate transaction after some operations succeed?

Answer: Hibernate wraps all operations in a transactional boundary. If an error occurs mid-transaction, Hibernate automatically rolls back the entire transaction, undoing all changes made so far. This ensures that the database remains in a consistent state and prevents partial updates. Whether you're using Hibernate's native Transaction API or Spring's @Transactional, the rollback mechanism guarantees atomicity—either all operations succeed, or none are committed.

Q: How do you track changes in entity data using Hibernate?

Answer: I use Hibernate Envers, a built-in module that automatically tracks changes to entity data. By annotating entities with @Audited, Envers creates audit tables and stores historical versions of the data, including inserts, updates, and deletes. This allows me to retrieve previous states of an entity and maintain a complete change history for compliance, debugging, or analytics.

Q: How do you map legacy tables and columns that don’t follow standard naming conventions in Hibernate?

Answer: I use the @Table and @Column annotations to explicitly map entity classes and fields to the legacy database's table and column names. This allows me to work with non-standard naming conventions without altering the schema.

@Entity

@Table(name = "legacy_user_table")

public class User {

@Id

@Column(name = "user_id")

private Long id;

@Column(name = "user_name")

private String name;

@Column(name = "user_email")

private String email;

}

Q: How do you implement caching in Spring JPA to improve performance?

Answer: I use the Spring Cache abstraction by annotating repository or service methods with @Cacheable. This stores the result of frequently accessed queries in a cache, reducing repeated database hits. I also configure a cache provider like EhCache or Redis in the application. For example, I enable caching with @EnableCaching and use @Cacheable("users") on methods that fetch user data.

🛠️ Quick Setup Steps

Enable caching in your Spring Boot app:

@SpringBootApplication
@EnableCaching
public class MyApp { }

2. Annotate methods to cache results:

@Cacheable("users")
public User getUserById(Long id) {
    return userRepository.findById(id).orElse(null);
}

3.Configure cache provider in application.properties:
spring.cache.type=redis
spring.redis.host=localhost
spring.redis.port=6379
spring.cache.redis.time-to-live=600000  # Optional: TTL in milliseconds
4. Evict or Update Cache When Needed

Keeps your cache in sync with DB updates.

@CacheEvict(value = "users", key = "#user.id")
public void updateUser(User user) {
    userRepository.save(user);
}

🧠 Why It Helps
Reduces database load
Speeds up response time for repeated queries
Improves scalability for read-heavy applications.


How do you handle schema migration in a project using Spring JPA when the schema changes 
due to business requirements ?

🧱 What Is a Database Schema?

A schema is the structure of your database — it defines:

Tables and their relationships
Columns, data types, constraints (e.g. primary keys, foreign keys)
Indexes, views, stored procedures, etc.

Think of it as the blueprint of your database.

When business requirements evolve (e.g. adding a new feature),

your schema might need to change — like adding a new column, renaming a table, or modifying constraints.

For schema migrations in Spring JPA projects, I integrate tools like Liquibase or Flyway. These tools are configured in Spring Boot applications to automatically apply database schema changes as part of the deployment process, ensuring the database schema is always in sync with the application's requirements.

Q: How do you manage bidirectional relationships in Spring JPA to avoid infinite recursion?

Answer: I manage bidirectional relationships by properly configuring @OneToMany, @ManyToOne, or @ManyToMany annotations with mappedBy.

To avoid infinite recursion during JSON serialization, I use Jackson annotations like @JsonManagedReference and @JsonBackReference, or I expose DTOs instead of entities. This ensures clean JSON output and avoids stack overflow errors.

🔁 What Jackson Does

Jackson is a library that converts Java objects to JSON and vice versa. When you have bidirectional relationships (like User → Order → User), Jackson tries to serialize everything — including nested objects — recursively.

🔄 How Infinite Recursion Happens

Imagine this setup:

@Entity

public class User {

@OneToMany(mappedBy = "user")

private List<Order> orders;

}

@Entity

public class Order {

@ManyToOne

private User user;

}

Now if you try to convert a User object to JSON:

new ObjectMapper().writeValueAsString(user);

Jackson will:

Serialize User
See orders → serialize each Order
Each Order has a user → serialize User again
That User has orders → and so on...

💥 Result: Infinite loop → StackOverflowError

🛠️ Easy Fix with Jackson Annotations

Use @JsonManagedReference and @JsonBackReference:

public class User {

@JsonManagedReference

private List<Order> orders;

}

public class Order {

@JsonBackReference

private User user;

}

✅ This tells Jackson:

Serialize orders inside User
But don’t serialize user inside Order again

Q: How do you optimize batch inserts in Spring JPA?

Answer: To optimize batch processing in Spring JPA, I configure spring.jpa.properties.hibernate.jdbc.batch_size in application.properties.

This enables Hibernate to group multiple insert/update statements into a single batch, reducing database round trips and significantly improving performance.

I also disable automatic flushing with spring.jpa.properties.hibernate.order_inserts=true and hibernate.order_updates=true to ensure efficient batching.

For large datasets, I manually flush and clear the persistence context periodically to avoid memory overhead.

🧠 What Is Flushing in Hibernate?

Flushing means:
Hibernate pushes changes from memory (Java objects) to the database — but doesn’t commit them yet.

🧾 Real-World Analogy

Imagine you're writing a document in MS Word:
You type changes — they’re in memory.
You hit Save — that’s like flush().
You hit Submit or Send — that’s like commit().
So:
flush() = sync changes to disk/database
commit() = finalize and make changes permanent

When Hibernate calls `flush()`, it sends the SQL statements (like `INSERT`, `UPDATE`, `DELETE`) to the database engine, but the changes are stored in the transaction buffer — not yet permanently saved.

⚙️ What Is Automatic Flushing?

Automatic flushing happens when Hibernate decides to flush changes without you explicitly calling flush(). This usually occurs:

Before a query is executed (to ensure query results reflect the latest changes)
Before committing a transaction

Hibernate uses FlushMode.AUTO by default, which means:

“Flush when needed — like before running a query or committing.”

🧠 What Does “Store in Memory” vs “Store in DB” Mean?

🗂️ Store in Memory

Means the data is temporarily held in RAM — fast, but not permanent. Hibernate does this inside the Session or cache before committing to the database.

Think of it like writing on a whiteboard — quick access, but if the power goes out, it’s gone.

🗄️ Store in Database

Means the data is persisted — saved permanently in your database (like MySQL, PostgreSQL, etc.).

Like saving a file to your hard drive — it stays even after shutdown.

🧠 Why Hibernate Uses Memory First

It lets you batch changes before hitting the DB
Improves performance by reducing DB round-trips
Supports rollback if something fails before commit

🔄 What Is the Transaction Buffer?

It’s a temporary area inside the database where changes are held during an open transaction.
These changes are not visible to other transactions.
If you call commit(), the buffer is flushed into the actual database tables.
If you call rollback(), the buffer is discarded — no changes are saved.

🔧 Summary

Hibernate Action	What Happens in DB
`save()`	Stored in Hibernate memory (not DB)
`flush()`	SQL sent to DB, stored in transaction buffer
`commit()`	Buffer is finalized → data saved permanently
`rollback()`	Buffer discarded → no changes saved

📚 What Is Pagination?

Pagination is the technique of breaking large datasets into smaller chunks (pages), so you don’t fetch everything at once. It improves performance, reduces memory usage, and gives better control over data display — especially in APIs and UI tables.

🛠️ How to Implement Pagination in Spring Data JPA

Spring Data makes pagination super easy using the Pageable interface and Page<T> result type.

🧠 Bonus Tip

For REST APIs, Spring Boot supports automatic pagination via @RequestParam:

@GetMapping("/users")

public Page<User> getUsers(@RequestParam int page, @RequestParam int size) {

return userRepository.findAll(PageRequest.of(page, size));

}