Last Updated: 

Hibernate: Unable to Find Entity with ID? Fixing EntityNotFoundException When Entity Exists

If you’ve worked with Hibernate (or JPA), you’ve likely encountered the dreaded javax.persistence.EntityNotFoundException (or its Hibernate-specific variant org.hibernate.EntityNotFoundException). The error message typically reads: "Unable to find [EntityName] with id [X]". What’s frustrating is when you’re certain the entity does exist in the database—you can query it directly with SQL and see the row!

This blog dives deep into why this exception occurs even when the entity exists and provides actionable solutions to fix it. Whether you’re a beginner or an experienced developer, you’ll learn to diagnose and resolve this common Hibernate pitfall.

Table of Contents#

  1. Understanding EntityNotFoundException
  2. Common Causes When the Entity Actually Exists
  3. Step-by-Step Fixes for Each Cause
  4. Prevention Tips to Avoid Future Issues
  5. References

Understanding EntityNotFoundException#

EntityNotFoundException is thrown by Hibernate when it cannot locate an entity in the database using the provided identifier (ID) during a lookup operation. Common methods that trigger this include:

  • EntityManager.find(Class<T> entityClass, Object id) (JPA)
  • Session.get(Class<T> entityClass, Serializable id) (Hibernate)
  • Session.load(Class<T> entityClass, Serializable id) (Hibernate, throws on proxy initialization if not found)

Key Note: find() and get() return null if the entity is not found, but some frameworks (e.g., Spring Data JPA’s getById()) wrap this in EntityNotFoundException for clarity. load() returns a proxy immediately and throws the exception later when the proxy is accessed if the entity is missing.

Common Causes When the Entity Actually Exists#

Let’s explore scenarios where the entity exists in the database, but Hibernate fails to find it.

1. ID Type Mismatch#

The most frequent culprit is a mismatch between the type of the entity’s ID and the type used in the lookup. For example:

  • Entity’s @Id is defined as Long, but the lookup uses a String (e.g., "123" instead of 123L).
  • The ID is a UUID (string-based), but the lookup passes a java.util.UUID instance instead of a String, or vice versa.

Hibernate will generate an SQL query with the wrong ID type, leading to a failed lookup even if the row exists.

2. Incorrect Database Schema or Catalog#

If your database uses schemas (e.g., PostgreSQL schemas) or catalogs, Hibernate might be querying the wrong schema/catalog. This happens if:

  • The entity’s @Table annotation lacks the schema or catalog attribute (defaults to the connection’s default schema).
  • The schema/catalog name is misspelled (e.g., schema = "public" vs. schema = "pubic").

3. Uncommitted Transactions#

Hibernate (and JPA) rely on transaction boundaries to persist changes. If you save an entity but forget to commit the transaction, subsequent lookups in a different transaction (or even the same uncommitted transaction) may fail.

Example scenario:

// Transaction 1: Save the entity (but do NOT commit)
entityManager.getTransaction().begin();
entityManager.persist(new User(1L, "John")); 
// Oops! Forgot to commit() or flush()
 
// Transaction 2: Look up the entity
User user = entityManager.find(User.class, 1L); // Returns null, leading to EntityNotFoundException

4. Stale Caching#

Hibernate uses two levels of caching to optimize performance:

  • First-Level Cache (Session Cache): A transaction-scoped cache that stores entities fetched during the current session.
  • Second-Level Cache: A cross-session cache shared across the application (if enabled).

If the cache contains stale data (e.g., an entity was deleted/updated externally but the cache wasn’t invalidated), Hibernate may return null even if the entity exists in the database.

5. Incorrect Entity Mapping#

Faulty mappings can cause Hibernate to generate invalid SQL queries. Common issues include:

  • @Id Placement: The @Id annotation is applied to a field but the entity uses property access (via getters/setters), or vice versa.
  • Composite IDs: Misconfigured composite IDs (e.g., missing @EmbeddedId or @IdClass, or mismatched ID components during lookup).
  • Discriminator Columns (for Inheritance): If using @Inheritance(strategy = InheritanceType.SINGLE_TABLE), a missing or incorrect @DiscriminatorValue can cause Hibernate to filter out valid entities.

6. Lazy Loading and Proxy Initialization#

Hibernate uses lazy loading for associations (e.g., @OneToMany(fetch = FetchType.LAZY)). If you load a parent entity and access a lazy child association, Hibernate may throw EntityNotFoundException if the child was deleted after the parent was fetched but before the association is accessed.

7. External Database Modifications#

If the entity was modified outside Hibernate (e.g., via a direct SQL script, another application, or a database trigger), Hibernate’s cache (first or second-level) may not reflect the latest state. For example:

  • You manually delete an entity via DELETE FROM users WHERE id = 1 but Hibernate’s first-level cache still thinks it exists.

Step-by-Step Fixes for Each Cause#

Let’s resolve each issue with concrete solutions.

Fix 1: Resolve ID Type Mismatch#

Step 1: Check the entity’s @Id type. For example:

@Entity
public class User {
    @Id
    private Long id; // ID type is Long
    private String name;
    // getters/setters
}

Step 2: Ensure the lookup uses the same type. Avoid casting or converting IDs manually:

// Correct: Use Long for lookup
Long userId = 123L; 
User user = entityManager.find(User.class, userId); 
 
// Incorrect: Using String "123" instead of Long 123L
String userIdStr = "123"; 
User user = entityManager.find(User.class, userIdStr); // Throws EntityNotFoundException

For UUIDs: Use consistent types (e.g., always String or always UUID):

@Entity
public class Product {
    @Id
    private UUID id; // ID type is UUID
    // ...
}
 
// Lookup with UUID type
UUID productId = UUID.fromString("a1b2c3d4-..."); 
Product product = entityManager.find(Product.class, productId);

Fix 2: Correct Schema/Catalog Configuration#

Step 1: Verify the entity’s @Table annotation includes the correct schema and catalog:

@Entity
@Table(name = "users", schema = "public", catalog = "my_db") // Explicit schema/catalog
public class User {
    @Id
    private Long id;
    // ...
}

Step 2: Confirm the database user has access to the specified schema. Run a test query to validate:

-- Check if the entity exists in the correct schema
SELECT * FROM public.users WHERE id = 123;

Fix 3: Ensure Proper Transaction Management#

Step 1: Always commit transactions after saving entities:

entityManager.getTransaction().begin();
entityManager.persist(new User(123L, "John"));
entityManager.getTransaction().commit(); // Critical: Commit the transaction
 
// Now lookup will succeed
User user = entityManager.find(User.class, 123L);

For Spring Users: Use @Transactional to auto-manage transactions:

@Service
public class UserService {
    @Autowired
    private EntityManager entityManager;
 
    @Transactional // Ensures commit after method execution
    public void saveUser() {
        entityManager.persist(new User(123L, "John"));
    }
 
    @Transactional(readOnly = true)
    public User getUser(Long id) {
        return entityManager.find(User.class, id); // Now finds the saved user
    }
}

Fix 4: Invalidate Stale Caching#

First-Level Cache: Clear the session cache to reload entities from the database:

// Evict a single entity from the first-level cache
entityManager.clear(); // Clears entire cache (use cautiously in production)
// OR
entityManager.evict(user); // Evict a specific entity

Second-Level Cache: If using a second-level cache (e.g., Ehcache), configure it to invalidate on updates:

<!-- In persistence.xml -->
<property name="hibernate.cache.use_second_level_cache" value="true"/>
<property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.jcache.JCacheRegionFactory"/>
<property name="hibernate.javax.cache.provider" value="org.ehcache.jsr107.EhcacheCachingProvider"/>

Evict Second-Level Cache: Manually evict entities if needed:

Session session = entityManager.unwrap(Session.class);
session.getSessionFactory().getCache().evictEntityRegion(User.class); // Evict entire User region

Fix 5: Correct Entity Mapping Issues#

@Id Placement: Ensure @Id is applied consistently (field or property access). For field access:

@Entity
public class User {
    @Id // Field access: @Id on the field
    private Long id; 
    private String name;
    // getters/setters (no @Id on getters)
}

Composite IDs: Use @EmbeddedId for embedded composite IDs:

@Embeddable
public class OrderId implements Serializable {
    private Long userId;
    private Long productId;
    // equals() and hashCode()
}
 
@Entity
public class Order {
    @EmbeddedId
    private OrderId id; // Composite ID
    private LocalDate orderDate;
    // getters/setters
}
 
// Lookup with composite ID
OrderId orderId = new OrderId(1L, 2L); 
Order order = entityManager.find(Order.class, orderId);

Fix 6: Handle Lazy Loading and External Modifications#

Refresh Entities: Reload the entity from the database to bypass the cache:

User user = entityManager.find(User.class, 123L); 
entityManager.refresh(user); // Reloads from DB, overriding cache

For Lazy Associations: Use fetch = FetchType.EAGER (not recommended for performance) or ensure the associated entity exists before accessing it:

@Entity
public class Order {
    @Id
    private Long id;
    @ManyToOne(fetch = FetchType.LAZY) // Lazy association
    private User user;
 
    // Access user only if it exists
    public String getUserName() {
        return user != null ? user.getName() : null;
    }
}

Prevention Tips to Avoid Future Issues#

  1. Enable SQL Logging: Log Hibernate’s generated SQL to verify the lookup query:

    # In application.properties (Spring Boot)
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true

    Example output:
    SELECT user0_.id AS id1_0_0_, user0_.name AS name2_0_0_ FROM users user0_ WHERE user0_.id=?
    Check if the ID value and type match the database.

  2. Unit Test ID Lookups: Write tests to validate ID type consistency:

    @Test
void testUserLookup() {
    Long userId = 123L;
    User user = userRepository.findById(userId).orElseThrow();
    assertEquals(userId, user.getId());
}

  3. Monitor Cache Behavior: Use tools like Hibernate’s Statistics to track cache hits/misses:

    Statistics stats = sessionFactory.getStatistics();
stats.setStatisticsEnabled(true);
System.out.println("Second-level cache hits: " + stats.getSecondLevelCacheHitCount());

References#

By systematically diagnosing ID types, transactions, caching, and mappings, you can resolve EntityNotFoundException even when the entity exists. Remember to validate with SQL logging and unit tests to prevent recurrence!

2025-11