Spring Framework & Hibernate

IoC means the framework, not your code, controls object creation and wiring. DI is the main IoC technique: a class declares its dependencies and the container supplies them.

• Benefits: loose coupling, easy substitution of collaborators in tests, centralized lifecycle management.
• The container is an ApplicationContext that reads configuration (annotations, Java config, XML) and builds a graph of beans.

BeanFactory is the minimal container interface (lazy bean creation, DI). ApplicationContext extends it and adds event publishing, MessageSource i18n, resource loading, environment/profile support, AOP integration and eager singleton initialization.

• Application code almost always uses ApplicationContext; BeanFactory is an internal building block.

Constructor, setter and field injection. Constructor injection is preferred.

• Constructor: dependencies are final, object is never half-built, trivial to unit test without Spring, circular dependencies fail fast.
• Setter: for optional or reconfigurable dependencies.
• Field (@Autowired on a field): hides dependencies, cannot be final, needs reflection in tests.
• Since Spring 4.3 a single constructor needs no @Autowired.

@Service
public class OrderService {
    private final OrderRepository repo;
    public OrderService(OrderRepository repo) { this.repo = repo; }
}

Autowiring is by type first. If multiple candidates remain, Spring uses @Primary, then @Qualifier, then falls back to matching the parameter/field name with the bean name. If still ambiguous it throws NoUniqueBeanDefinitionException.

• @Qualifier("name") is explicit at the injection point and wins over @Primary.
• Injecting List<T> or Map<String,T> collects all beans of the type.

All are stereotype annotations meta-annotated with @Component, so component scanning registers them as beans. The specialization conveys the layer and adds behavior in two cases.

• @Repository: enables persistence exception translation to DataAccessException through a post-processor.
• @Controller/@RestController: detected by Spring MVC as request handlers.
• @Service: purely semantic.

Use component scanning for your own classes; use @Bean methods in @Configuration classes for third-party classes or when construction needs logic.

• @Configuration classes are CGLIB-proxied (full mode) so that calling one @Bean method from another returns the same singleton instead of creating a new object.
• @Configuration(proxyBeanMethods = false) (lite mode) skips the proxy for faster startup when no inter-bean method calls exist; Boot's own auto-configurations use it.

singleton (default, one per container), prototype (new instance per request for the bean), and in web contexts request, session, application and websocket. Custom scopes can be registered.

• Singleton is per container, not per JVM and not like the GoF pattern.
• Spring does not manage the full lifecycle of prototypes: destroy callbacks are not called.

Injecting directly resolves the prototype once at singleton creation, so you get the same instance forever. Fix it by injecting an ObjectProvider<T> (call getObject()), a lookup method (@Lookup), or a scoped proxy.

@Component
class Runner {
    private final ObjectProvider<Task> tasks;
    Runner(ObjectProvider<Task> tasks) { this.tasks = tasks; }
    void run() { tasks.getObject().execute(); } // new Task each call
}

Instantiate -> populate properties (DI) -> *Aware callbacks -> BeanPostProcessor.postProcessBeforeInitialization -> @PostConstruct -> InitializingBean.afterPropertiesSet -> custom init-method -> postProcessAfterInitialization (where AOP proxies are created) -> bean in use -> on shutdown @PreDestroy -> DisposableBean.destroy -> custom destroy method.

• @PostConstruct/@PreDestroy are in jakarta.annotation since Spring 6 / Boot 3 (javax before).

For singleton beans with setter/field injection Spring exposes early references via a three-level cache and resolves the cycle. With constructor injection it cannot, and throws BeanCurrentlyInCreationException.

• Since Spring Boot 2.6 circular references are prohibited by default (spring.main.allow-circular-references=false).
• Real fix: redesign (extract a third bean, use events), or break with @Lazy on one injection point.

It is a composite of @SpringBootConfiguration (a @Configuration), @EnableAutoConfiguration and @ComponentScan rooted at the annotated class's package.

• Beans outside the main class's package tree are not scanned unless scanBasePackages is set.

@EnableAutoConfiguration imports classes listed in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (Boot 2.7+/3.x; formerly spring.factories). Each is a @Configuration guarded by conditions such as @ConditionalOnClass, @ConditionalOnMissingBean, @ConditionalOnProperty.

• Because of @ConditionalOnMissingBean, your own bean always backs off the default.
• Run with --debug or use the actuator conditions endpoint to see the condition evaluation report.

Starters are curated dependency descriptors (for example spring-boot-starter-web, -data-jpa, -test, -validation, -actuator) that pull a consistent set of libraries. They contain no code of note; the auto-configuration module does the wiring.

• Version alignment comes from the spring-boot-dependencies BOM through spring-boot-starter-parent or the dependency-management plugin.

Profiles group beans and properties per environment. Activate with spring.profiles.active=prod, an env var SPRING_PROFILES_ACTIVE, or --spring.profiles.active. Beans use @Profile("dev"); properties live in application-dev.yml and override the base file.

• A profile expression like @Profile("!prod") or "dev & local" is supported.
• Boot 2.4+ also supports spring.config.activate.on-profile inside multi-document YAML.

Higher wins: command-line args, SPRING_APPLICATION_JSON, OS environment variables, profile-specific files outside the jar, profile-specific files inside the jar, application.properties/yml outside, then inside the jar, @PropertySource, and finally defaults.

• Env var MY_APP_DB_URL maps to my.app.db.url through relaxed binding.
• This is how a container overrides a packaged default without rebuilding.

@Value("${key:default}") injects a single value with SpEL support. @ConfigurationProperties(prefix="app") binds a hierarchy to a typed bean with relaxed binding, validation and IDE metadata. Prefer the latter for groups of settings.

@ConfigurationProperties(prefix = "app.mail")
@Validated
public record MailProps(@NotBlank String host, @Min(1) int port) {}

• Register with @EnableConfigurationProperties or @ConfigurationPropertiesScan; records use constructor binding in Boot 3.

Aspect-oriented programming modularizes cross-cutting concerns (logging, security, transactions, metrics).

• Aspect: class holding the concern. Advice: the action (@Before, @After, @AfterReturning, @AfterThrowing, @Around).
• Join point: a point in execution (in Spring AOP always a method execution). Pointcut: expression selecting join points.
• Weaving: linking aspects to targets; Spring does it at runtime via proxies.

If the bean implements an interface, a JDK dynamic proxy may be used; otherwise a CGLIB subclass proxy. Spring Boot defaults to CGLIB (spring.aop.proxy-target-class=true) even when interfaces exist.

• CGLIB cannot proxy final classes or final/private methods.
• Callers get the proxy; the proxy runs advice then delegates to the target.

Advice lives in the proxy. A call this.method() inside the target goes straight to the raw object, never through the proxy, so no advice runs.

• Fixes: move the method to another bean, inject the proxy (self-injection with @Lazy), use AopContext.currentProxy() with exposeProxy=true, or use AspectJ weaving.

The request hits DispatcherServlet (front controller) -> HandlerMapping finds the handler and interceptors -> HandlerAdapter invokes the controller method, resolving arguments (@PathVariable, @RequestBody) via HandlerMethodArgumentResolvers -> return value handled by HttpMessageConverter (for @ResponseBody) or a ViewResolver + view -> response.

• Exceptions go to HandlerExceptionResolvers such as @ExceptionHandler/@ControllerAdvice.
• Servlet filters run before DispatcherServlet; HandlerInterceptors run after mapping.

@PathVariable binds a URI template segment (/users/{id}), @RequestParam a query/form parameter, @RequestBody deserializes the body via a message converter.

• @RequestParam is required by default; use required=false or defaultValue.
• Using a missing required param yields HTTP 400.

Use @RestControllerAdvice with @ExceptionHandler methods mapping exceptions to responses. Spring 6 / Boot 3 supports RFC 7807 ProblemDetail (spring.mvc.problemdetails.enabled=true) and ResponseEntityExceptionHandler.

@RestControllerAdvice
class Errors {
    @ExceptionHandler(NotFoundException.class)
    ProblemDetail notFound(NotFoundException e) {
        return ProblemDetail.forStatusAndDetail(HttpStatus.NOT_FOUND, e.getMessage());
    }
}

@ResponseStatus fixes a status on a method or exception class. ResponseEntity<T> lets you set status, headers and body dynamically per call.

• Default status for @ResponseBody return is 200; returning void with @ResponseStatus(NO_CONTENT) gives 204.

MVC is servlet-based and blocking, one thread per request. WebFlux is non-blocking, built on Reactor (Mono/Flux) over Netty or servlet 3.1+ async, using few event-loop threads.

• WebFlux helps with high concurrency and streaming, but only if the whole chain (including DB drivers) is non-blocking.
• Java 21 virtual threads (spring.threads.virtual.enabled=true, Boot 3.2) let MVC scale blocking code with much less rewrite.

JdbcTemplate removes JDBC boilerplate: it acquires/releases connections, prepares statements, iterates ResultSets, and translates SQLException into the unchecked DataAccessException hierarchy.

List<User> users = jdbc.query(
    "select id, name from users where active = ?",
    (rs, i) -> new User(rs.getLong("id"), rs.getString("name")),
    true);

NamedParameterJdbcTemplate uses :name parameters, avoiding positional errors and allowing IN (:ids) with collections. JdbcClient (Spring 6.1) is a fluent facade over both.

jdbcClient.sql("select * from users where status = :s")
          .param("s", "ACTIVE")
          .query(User.class).list();

• SimpleJdbcInsert and KeyHolder help fetch generated keys.

JPA (Jakarta Persistence) is a specification of interfaces and annotations. Hibernate is the most common implementation. Spring Data JPA is a layer on top that generates repository implementations and uses JPA (so Hibernate) underneath.

• Boot 3 uses Hibernate 6 and the jakarta.persistence package (was javax.persistence).

• Transient/new: not associated with a persistence context, no row.
• Managed/persistent: attached to a session; changes are tracked and flushed.
• Detached: was managed, its session closed or cleared.
• Removed: scheduled for deletion on flush.

Transitions: persist (new -> managed), find/query (-> managed), detach/clear/close (managed -> detached), merge (detached -> managed copy), remove (managed -> removed).

The persistence context is the per-EntityManager/Session identity map. It guarantees one instance per entity id, caches loaded entities, and tracks changes for dirty checking. It is always on and cannot be disabled.

• em.find twice with the same id hits the database once.
• JPQL queries still execute SQL, but returned rows resolve to already-managed instances.

On load Hibernate stores a snapshot of each entity's state. At flush it compares current state to the snapshot and issues UPDATEs for differences, so no explicit save is needed for a managed entity.

• Flush happens at commit, before a JPQL/HQL query that touches affected tables (FlushMode.AUTO), or on explicit flush().
• Flush sends SQL; commit makes it durable.

persist makes a new entity managed (same instance) and returns void. merge copies state of a detached/new object onto a managed instance and returns that instance; the argument stays unmanaged. Hibernate's save/saveOrUpdate are legacy native APIs (deprecated in 6, removed later). Spring Data's save calls persist if isNew() else merge.

• isNew() is true when the id is null (or the version is null for a wrapper-typed @Version).

@OneToOne, @OneToMany, @ManyToOne, @ManyToMany. The owning side holds the foreign key; the inverse side uses mappedBy.

• Best practice: prefer a bidirectional @OneToMany with @ManyToOne as owner, or only unidirectional @ManyToOne.
• @ManyToMany hides a join table; model an explicit join entity when it needs extra columns.
• @JoinColumn names the FK column.

LAZY loads the association on first access via a proxy or lazy collection; EAGER loads it with the owner. Defaults: @ManyToOne and @OneToOne are EAGER; @OneToMany and @ManyToMany are LAZY.

• Best practice: set @ManyToOne(fetch = LAZY) and fetch what you need per query (JOIN FETCH, entity graphs).

Loading N parents then touching a lazy association on each issues 1 + N queries. Fix by fetching together: JOIN FETCH, @EntityGraph, @BatchSize/default_batch_fetch_size, or a DTO projection.

@Query("select o from Order o join fetch o.items where o.status = :s")
List<Order> findWithItems(@Param("s") Status s);

It is thrown when a lazy association or proxy is accessed after its session closed. Fix by loading what you need inside the transaction (fetch join, entity graph, DTO), not by switching to EAGER globally.

• spring.jpa.open-in-view (default true in Boot) keeps the session open through the web layer and hides the problem, at the cost of holding a connection longer.

cascade propagates entity operations (PERSIST, MERGE, REMOVE, REFRESH, DETACH, ALL) from parent to child. orphanRemoval = true deletes a child removed from the parent's collection.

• Use only for true parent-owned children (composition), never CascadeType.ALL on @ManyToOne or shared entities.

IDENTITY uses auto-increment columns: simple, but the insert must happen immediately to know the id, disabling JDBC insert batching. SEQUENCE fetches ids from a DB sequence (with allocationSize pooling), allowing batching. AUTO picks per dialect (sequence on PostgreSQL/Oracle in Hibernate 6). TABLE is slow and rarely used. UUID is supported directly.

@Version enables optimistic locking. Hibernate adds where version = ? to updates and increments it; if no row matches, it throws OptimisticLockException (ObjectOptimisticLockingFailureException in Spring).

• No DB lock is held, so it suits low-contention updates; callers handle the exception with a retry or an error to the user.
• Pessimistic alternative: LockModeType.PESSIMISTIC_WRITE (select ... for update).

JPQL queries entities and their fields rather than tables and columns, is database independent, and is translated to SQL by the provider. Native queries run raw SQL when you need vendor features.

TypedQuery<User> q = em.createQuery(
    "select u from User u where u.email = :email", User.class);
q.setParameter("email", email);

The Criteria API builds queries programmatically and type-safely, ideal for dynamic filters where predicates are added conditionally.

CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<User> cq = cb.createQuery(User.class);
Root<User> u = cq.from(User.class);
cq.select(u).where(cb.equal(u.get("status"), "ACTIVE"));
List<User> r = em.createQuery(cq).getResultList();

• Spring Data's Specification wraps Criteria; Querydsl is a popular alternative.

You declare an interface extending JpaRepository<T, ID> (or CrudRepository, PagingAndSortingRepository). Spring creates a JDK proxy at startup backed by SimpleJpaRepository, supporting CRUD, paging, sorting, derived queries, @Query and projections.

interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByEmailIgnoreCase(String email);
    List<User> findByStatusOrderByCreatedAtDesc(Status s);
}

Pass a Pageable (PageRequest.of(page, size, Sort)) and return Page<T> (runs an extra count query), Slice<T> (fetches size+1 to know if there is a next page, no count) or List<T>.

• Page numbers are zero-based.
• Offset paging degrades on deep pages; keyset (seek) pagination or Window (3.1+) scales better.

It wraps a method in a transaction through an AOP proxy: begin before, commit on success, rollback on failure. Defaults: propagation REQUIRED, isolation DEFAULT (database default), readOnly=false, no timeout.

• Rolls back on unchecked exceptions (RuntimeException, Error) but commits on checked exceptions unless rollbackFor is set.
• Applies only to calls entering through the Spring proxy, on public methods (for proxy-based AOP).

• REQUIRED (default): join existing or create new.
• REQUIRES_NEW: suspend current, always run in a new independent transaction.
• SUPPORTS: join if present, else non-transactional.
• MANDATORY: must have one, else exception.
• NOT_SUPPORTED: suspend and run without one.
• NEVER: fail if one exists.
• NESTED: savepoint inside the outer transaction (JDBC only; JPA/Hibernate transaction manager does not support it).

READ_UNCOMMITTED allows dirty reads; READ_COMMITTED prevents dirty reads; REPEATABLE_READ also prevents non-repeatable reads; SERIALIZABLE also prevents phantoms. Higher isolation costs concurrency.

• PostgreSQL and Oracle default to READ_COMMITTED; MySQL InnoDB to REPEATABLE_READ.
• Set per method with @Transactional(isolation = ...).

Add spring-boot-starter-validation (Hibernate Validator). Annotate fields with constraints (@NotNull, @NotBlank, @Size, @Email, @Min) and trigger with @Valid/@Validated on a @RequestBody parameter. Failures raise MethodArgumentNotValidException (400).

public record SignUp(@NotBlank String name, @Email String email) {}

@PostMapping("/users")
ResponseEntity<Void> create(@Valid @RequestBody SignUp req) { ... }

@Valid is the standard Jakarta annotation and cascades into nested objects. @Validated is Spring's variant that supports validation groups and, at class level, enables method-level validation of parameters on any bean via a proxy.

• Method validation of @PathVariable/@RequestParam constraints needs @Validated on the controller (Spring 6.1 built-in handler validation makes this implicit).
• Violations there throw ConstraintViolationException (or HandlerMethodValidationException in 6.1).

@SpringBootTest loads the full context (add webEnvironment for a real or random port). Slices load only a layer: @WebMvcTest (controllers + MVC infrastructure, with MockMvc), @DataJpaTest (JPA + embedded DB, transactional rollback per test), @JsonTest, @RestClientTest, @DataJdbcTest.

• @MockBean (deprecated in Boot 3.4 for @MockitoBean) replaces a bean with a mock in the context.

Unit-test services with plain JUnit 5 and Mockito (@ExtendWith(MockitoExtension.class)), no Spring context, relying on constructor injection. For persistence, use @DataJpaTest against Testcontainers with the production database engine (Boot 3.1+ @ServiceConnection wires the URL automatically).

• Embedded H2 can hide dialect differences (JSON, locking, sequences).

Actuator adds production endpoints for health, metrics, info, environment, beans, mappings, loggers, thread dumps and more, via spring-boot-starter-actuator. Over HTTP only health is exposed by default; others need management.endpoints.web.exposure.include.

management:
  endpoints.web.exposure.include: health,info,prometheus
  endpoint.health.show-details: when-authorized

• Metrics use Micrometer and can export to Prometheus and others.

/actuator/health aggregates HealthIndicator beans (db, disk, custom). On Kubernetes, Boot exposes /actuator/health/liveness and /readiness groups (auto-enabled in a detected K8s environment or via management.endpoint.health.probes.enabled=true).

• Readiness should reflect ability to take traffic; liveness should only fail when a restart helps.
• Do not include downstream dependencies in liveness, or an outage restarts every pod.

The second-level cache is a SessionFactory-wide cache of entity state shared across sessions, off by default, enabled with a JCache/Ehcache/Infinispan provider and @Cacheable plus a cache concurrency strategy. The query cache stores id lists for queries and depends on the L2 cache.

• Good for read-mostly reference data; invalidated per table on writes.
• Not cluster-coherent without a distributed provider.

No. The inner call is this.inner(), bypassing the proxy, so its @Transactional(propagation = REQUIRES_NEW) is ignored and it runs in the caller's transaction (or none, if the caller is not transactional).

• Move inner into another bean, or inject the proxy of the bean itself.

Yes, it is committed. Default rollback rules cover only RuntimeException and Error. Use @Transactional(rollbackFor = IOException.class) (or Exception.class) to roll back.

Nothing: proxy-based AOP only intercepts calls through the proxy, and private methods are not proxied (CGLIB cannot override them; the JDK proxy sees only interface methods). No transaction starts and no error is raised. Since Spring 6, protected/package-private methods work with class-based proxies, but private still does not.

Put the audit write in a separate bean method annotated @Transactional(propagation = REQUIRES_NEW) and call it through the proxy. It commits independently when it returns.

@Service
class AuditService {
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void record(String event) { repo.save(new Audit(event)); }
}

OpenEntityManagerInViewInterceptor binds one EntityManager to the whole web request, so the session stays open after the service transaction ends and lazy loads still succeed (each triggers an auto-commit query). With it off, the session closes at the end of the @Transactional method.

• Fix properly: fetch the items in the service (join fetch, @EntityGraph) or map to a DTO there.

Classic N+1: one query for orders plus one per order for a lazy (or eager) association. Confirm with spring.jpa.show-sql or Hibernate statistics, then use @EntityGraph(attributePaths = "customer") or join fetch, or set spring.jpa.properties.hibernate.default_batch_fetch_size=50 to turn N into N/50 IN queries.

@EntityGraph(attributePaths = {"customer"})
List<Order> findByStatus(Status s);

Hibernate cannot apply LIMIT to a joined row set (it would cut parent rows), so it fetches all rows, paginates in memory and logs HHH000104: firstResult/maxResults specified with collection fetch; applying in memory. This can blow up memory.

• Workaround: paginate parent ids in one query, then fetch the collections for those ids in a second query, or use batch fetching.

Yes. The entity is managed, so dirty checking at flush/commit detects the change and issues an UPDATE. Outside a transaction (or on a detached entity), nothing is written.

@Transactional
void demo(Long id) {
    User a = em.find(User.class, id);
    User b = em.find(User.class, id);
    System.out.println(a == b);
}

Prints true, with only one SELECT. The second find is served from the persistence context identity map. In two separate transactions (two sessions) you get two SELECTs and different instances.

With FlushModeType.AUTO (default), Hibernate flushes pending changes before executing a query that touches the affected tables, so the query sees them. Native queries on Hibernate with JPA flush everything under JPA bootstrapping, but may not under native Session API unless synchronized.

• With COMMIT mode, the query does not see pending changes.

Bulk JPQL updates execute directly in the database and do not update entities already loaded in the persistence context; subsequent find returns the cached stale instance.

@Modifying(clearAutomatically = true, flushAutomatically = true)
@Query("update User u set u.status = 'INACTIVE' where u.lastLogin < :d")
int deactivate(@Param("d") Instant d);

IDENTITY forces each insert to execute immediately to fetch the key, so Hibernate silently disables JDBC insert batching. Switch to SEQUENCE with allocationSize matching the sequence increment and set hibernate.jdbc.batch_size=50 (plus order_inserts=true). Also clear/flush periodically to bound the persistence context.

Add a @Version column. The second commit's update ... where id=? and version=? matches zero rows and Hibernate throws OptimisticLockException. Handle it by returning 409 or retrying.

@Entity
class Account {
    @Id Long id;
    @Version long version;
    BigDecimal balance;
}

Parent serializes children, each child serializes the parent, forever. Fix by returning DTOs from controllers (best), or use @JsonIgnore, @JsonManagedReference/@JsonBackReference, or @JsonIdentityInfo.

• Serializing entities also risks triggering lazy loads or exposing internal fields.

@Data generates equals/hashCode/toString over all fields including relations: lazy collections get initialized (or throw LazyInitializationException), cycles recurse, and a mutable generated id or fields change hashCode while the entity sits in a HashSet.

• Use @Getter/@Setter, base equals on a business key, or on the id with a constant hashCode pattern and null-id handling.

findById hits the DB immediately and returns the entity or empty. getReferenceById returns a lazy proxy without a query; the SELECT happens on first property access, throwing EntityNotFoundException if absent. Use it to set an FK without loading the row.

order.setCustomer(customerRepo.getReferenceById(customerId));

@Service class A { A(B b) {} }
@Service class B { B(A a) {} }

The context fails to start with BeanCurrentlyInCreationException / UnsatisfiedDependencyException describing the cycle. Even with setter injection, Boot 2.6+ refuses cycles by default.

• Refactor so the dependency goes one way (extract shared logic to C) or publish an event.

The singleton's dependencies are resolved once at its creation, so the prototype is instantiated one time. Use ObjectProvider<T>, @Lookup, or @Scope(value="prototype", proxyMode=TARGET_CLASS) so each use gets a fresh instance.

NoUniqueBeanDefinitionException: expected single matching bean but found 2. Resolve with @Primary on the default, @Qualifier("stripe") at the injection point, naming the parameter after the bean, or injecting Map<String, PaymentGateway> for strategy selection.

PaymentService(@Qualifier("stripe") PaymentGateway gw) { this.gw = gw; }

Typical causes: your bean has a different type than the one checked (for example you declare the implementation with another return type), it is defined in a configuration not scanned, or it is registered after the auto-config is evaluated. Use --debug or /actuator/conditions to see why the condition matched.

• Declare the @Bean with the same type or interface the auto-config tests for.

The environment variable APP_TIMEOUT wins; it outranks packaged config files, including application-prod.yml. Between the two files, application-prod.yml overrides application.yml. A command-line argument --app.timeout= would beat all.

• The class is not registered (@EnableConfigurationProperties or @ConfigurationPropertiesScan missing, or no @Component).
• Wrong prefix or key names (relaxed binding still requires matching words).
• No setters on a mutable class (JavaBean binding) or missing constructor binding on an immutable one.
• The profile file is not active.

Check the package: scanning starts from the @SpringBootApplication class's package. A class in a sibling package (com.other) is missed; fix by moving it or using scanBasePackages/@ComponentScan. Also verify the stereotype annotation and that no profile or conditional excludes it.

The request Content-Type is missing or not supported by any HttpMessageConverter for the parameter type, or the mapping declares consumes that does not match. For JSON, send Content-Type: application/json and ensure Jackson is on the classpath.

Boot's auto-configured ObjectMapper disables FAIL_ON_UNKNOWN_PROPERTIES, so unknown fields are silently ignored. A raw new ObjectMapper() would fail with UnrecognizedPropertyException (400). Missing fields become null/default.

• Enable strictness with spring.jackson.deserialization.fail-on-unknown-properties=true.

Common reasons: spring-boot-starter-validation is absent (no validator on the classpath), @Valid is missing on the parameter, constraints are on a getter of a record/class improperly, or nested objects lack @Valid.

Handle MethodArgumentNotValidException in a @RestControllerAdvice and map getBindingResult().getFieldErrors().

@ExceptionHandler(MethodArgumentNotValidException.class)
ResponseEntity<Map<String,String>> invalid(MethodArgumentNotValidException e) {
    Map<String,String> m = new LinkedHashMap<>();
    e.getBindingResult().getFieldErrors()
        .forEach(f -> m.put(f.getField(), f.getDefaultMessage()));
    return ResponseEntity.badRequest().body(m);
}

@WebMvcTest loads only the web slice, not @Service/@Repository beans, so the controller's dependency is missing. Provide a mock with @MockitoBean (or @MockBean before Boot 3.4).

@WebMvcTest(OrderController.class)
class OrderControllerTest {
    @Autowired MockMvc mvc;
    @MockitoBean OrderService service;
}

H2 differs in dialect, JSON/array types, case sensitivity, locking, sequence behavior and function support, and @DataJpaTest replaces your datasource by default. Use Testcontainers with the production engine and @AutoConfigureTestDatabase(replace = NONE) (or @ServiceConnection).

Test transactions roll back by default, so Hibernate may never flush: constraint violations, lazy-loading issues and version conflicts do not appear. Call em.flush()/flush(); clear() in the test to force SQL and a fresh load, or use @Commit / a non-transactional integration test.

Separate concerns: point the Kubernetes liveness probe to /actuator/health/liveness (internal state only), and the readiness probe to a group containing only critical indicators. Disable or exclude the mail indicator (management.health.mail.enabled=false) or move it out of the readiness group.

management:
  endpoint.health:
    probes.enabled: true
    group.readiness.include: readinessState,db

env, configprops, heapdump, threaddump, loggers (changing log levels), beans and mappings reveal configuration, secrets (masked only partially) and internals; heapdump leaks memory contents. Expose only health/info/prometheus, put management behind authentication or on a separate internal port, and sanitize values (show-values).

It is open to SQL injection: input such as x' OR '1'='1 changes the query. Use ? placeholders or named parameters so the driver sends values separately.

jdbc.query("select * from users where name = ?", mapper, name);

queryForObject expects exactly one row: zero rows give EmptyResultDataAccessException, more than one gives IncorrectResultSizeDataAccessException. Use query(...) and take the first element, .stream().findFirst(), or JdbcClient...optional().

Use batchUpdate in chunks inside one transaction.

jdbc.batchUpdate(
    "insert into item(sku, qty) values (?, ?)", items, 500,
    (ps, it) -> { ps.setString(1, it.sku()); ps.setInt(2, it.qty()); });

• With PostgreSQL add reWriteBatchedInserts=true; with MySQL rewriteBatchedStatements=true in the JDBC URL.

Self-calls bypass the proxy. Extract the advised method into a collaborator bean, or call it via an injected proxy of itself. If the aspect must cover internal calls, use AspectJ compile- or load-time weaving.

@Aspect
@Component
class TimingAspect {
    @Around("@annotation(com.app.Timed)")
    Object time(ProceedingJoinPoint pjp) throws Throwable {
        long t = System.nanoTime();
        try {
            return pjp.proceed();
        } finally {
            long ms = (System.nanoTime() - t) / 1_000_000;
            System.out.println(pjp.getSignature() + " took " + ms + " ms");
        }
    }
}

Forgetting pjp.proceed() means the target is never called; swallowing exceptions changes behavior.

Order is controlled by @Order/Ordered (lower value = outermost). The transaction advisor has lowest precedence by default (Ordered.LOWEST_PRECEDENCE), so your aspect wraps the transaction unless you set a different order. A retry aspect must be ordered outside the transaction aspect so each retry gets a fresh transaction.

Context startup fails with PropertyReferenceException: No property 'emial' found for type 'User', because derived queries are parsed when the repository proxy is created. @Query methods are validated too (JPQL syntax checked at startup).

For a single-entity return type Spring Data throws IncorrectResultSizeDataAccessException. Fix the data model (unique constraint on email), return a List, or use findFirstBy.../findTopBy....

Use an interface or record projection; Spring Data generates a narrow SELECT.

record UserSummary(Long id, String name) {}

interface UserRepository extends JpaRepository<User, Long> {
    List<UserSummary> findByStatus(Status status);
}

• Interface projections with nested/SpEL properties may load the whole entity; closed projections select only required columns.

Page runs a count(*) on each request and OFFSET n forces the database to skip n rows. Return Slice to skip the count, cache or approximate totals, and switch to keyset pagination (where id > :lastId order by id limit :size) using a stable sort key and an index.

isNew() checks if the id (or @Version) is null; a pre-assigned id means "not new", so save calls merge, which SELECTs to see whether the row exists. Implement Persistable<ID> returning isNew() == true for fresh instances (typically tracked with a @Transient flag), or use a generated id.

The DB rejects deleting a parent whose rows are referenced. Options: cascade = REMOVE (or orphanRemoval) so Hibernate deletes children first, ON DELETE CASCADE on the FK, or delete children explicitly. CascadeType.REMOVE loads and deletes children one by one; DB-level cascade is faster for large sets.

The FK is written from the owning side (@ManyToOne on the child). Adding to the inverse collection alone does not set child.parent, so the column stays null. Keep both sides in sync with a helper.

void addChild(Child c) { children.add(c); c.setParent(this); }

update auto-alters schema on startup but never drops columns, cannot rename or migrate data, is unreviewed and unreversible, and may lock tables. Use Flyway or Liquibase for versioned migrations and ddl-auto=validate (or none) in production.

• Defaults in Boot: create-drop for embedded DBs, none for others.

The DB connection stays checked out while waiting on the network, so slow responses exhaust the Hikari pool (default 10) and requests queue with Connection is not available timeouts. Keep transactions short: call external services outside the transaction or after commit (@TransactionalEventListener(phase = AFTER_COMMIT)).

The listener runs after the original transaction has committed but its transaction resources are still bound, so a plain @Transactional (REQUIRED) joins the finished transaction and nothing is committed. Annotate the listener with @Transactional(propagation = REQUIRES_NEW).

@Async runs the method on another thread; the transaction is thread-bound, so the caller's transaction does not extend into it. The async method starts its own transaction if it carries @Transactional. Exceptions are lost for void returns unless an AsyncUncaughtExceptionHandler is set, and self-invocation again bypasses both.

@RequestScope sets proxyMode = TARGET_CLASS by default, so the singleton receives a proxy that delegates to the current request's instance. Outside a request thread (an async or scheduled job) it throws IllegalStateException: No thread-bound request found.

Boot detected spring-boot-starter-data-jpa or JDBC but no spring.datasource.url (and no embedded DB on the classpath). Provide the URL, username, password and the JDBC driver dependency, or exclude DataSourceAutoConfiguration if no DB is needed.

Set server.port in properties, CLI (--server.port=8081) or env (SERVER_PORT); use server.port=0 for a random port in tests (@LocalServerPort reads it). Otherwise stop the process holding the port.