DEV Community: Thellu

# Stop Letting Jackson Accept Garbage: Strict JSON Parsing in Spring Boot

Thellu — Sun, 29 Mar 2026 18:46:33 +0000

Most Spring Boot APIs think they are strict — until a client sends something slightly “off”, and your app quietly accepts it.

Examples I’ve seen in real systems:

"count": "10" (string) accepted where you expected an integer
"amount": 1.2 accepted where you expected an integer cents value
"age": "" becoming 0 or null depending on coercion rules
unknown fields being ignored (and bugs staying hidden for months)

If you care about contracts, lenient deserialization is technical debt. The earlier you fail, the cheaper it is.

This post shows a practical way to make JSON parsing predictable and strict in Spring Boot, without turning your codebase into a pile of custom validators.

What “strict” means (pick your rules)

There’s no universal strictness. Define your contract.

A reasonable default for backend APIs:

Unknown fields fail (clients can’t silently send typos)
Wrong types fail (string vs number, boolean vs string, etc.)
No “magical” coercions ("" → null, "10" → 10, 1.0 → 1, etc.)
Numbers are validated (no NaN/Infinity; integer overflow fails)
Error responses are consistent (clients can handle them)

Step 1) Turn off “accept anything” defaults

Create a single ObjectMapper configuration. In Spring Boot, the cleanest way is to customize Jackson2ObjectMapperBuilder.

import com.fasterxml.jackson.databind.DeserializationFeature;
import com.fasterxml.jackson.databind.MapperFeature;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.cfg.CoercionAction;
import com.fasterxml.jackson.databind.cfg.CoercionInputShape;
import com.fasterxml.jackson.databind.type.LogicalType;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.converter.json.Jackson2ObjectMapperBuilderCustomizer;

@Configuration
public class StrictJacksonConfig {

  @Bean
  public Jackson2ObjectMapperBuilderCustomizer strictJacksonCustomizer() {
    return builder -> builder.postConfigurer(this::configureStrictness);
  }

  private void configureStrictness(ObjectMapper mapper) {
    // 1) Unknown fields should fail
    mapper.enable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES);

    // 2) Don’t accept null for primitives (helps catch missing fields)
    mapper.enable(DeserializationFeature.FAIL_ON_NULL_FOR_PRIMITIVES);

    // 3) Be explicit about coercions (Jackson 2.12+)
    mapper.coercionConfigFor(LogicalType.Integer)
        .setCoercion(CoercionInputShape.String, CoercionAction.Fail)
        .setCoercion(CoercionInputShape.Float, CoercionAction.Fail)
        .setCoercion(CoercionInputShape.EmptyString, CoercionAction.Fail);

    mapper.coercionConfigFor(LogicalType.Float)
        .setCoercion(CoercionInputShape.String, CoercionAction.Fail)
        .setCoercion(CoercionInputShape.EmptyString, CoercionAction.Fail);

    mapper.coercionConfigFor(LogicalType.Boolean)
        .setCoercion(CoercionInputShape.String, CoercionAction.Fail)
        .setCoercion(CoercionInputShape.EmptyString, CoercionAction.Fail);

    // 4) Optional: enforce exact property names (rarely needed, but useful for hard contracts)
    mapper.disable(MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES);
  }
}

Why this matters

With these rules:

"count": "10" fails instead of being accepted
"count": 10.0 fails instead of being coerced to 10
"count": "" fails instead of becoming 0/null
"unknowField": 123 fails immediately

This shifts bugs from “production data weirdness” to “client gets a 400”.

Step 2) Define “strict numbers” (the part Jackson won’t solve alone)

Even with coercions disabled, some numeric edge cases still need explicit handling:

leading/trailing spaces
+10, 01 (maybe you want to reject)
scientific notation for integers: 1e3
extremely large numbers that overflow int/long
decimal formatting rules (for money you may want to accept only strings or only decimals)

For fields where it matters, use a custom deserializer.

Example: strict integer deserializer

import com.fasterxml.jackson.core.JsonParser;
import com.fasterxml.jackson.databind.DeserializationContext;
import com.fasterxml.jackson.databind.JsonDeserializer;
import com.fasterxml.jackson.databind.JsonMappingException;
import com.fasterxml.jackson.databind.JsonNode;

import java.io.IOException;

public class StrictIntDeserializer extends JsonDeserializer<Integer> {

  @Override
  public Integer deserialize(JsonParser p, DeserializationContext ctxt) throws IOException {
    JsonNode node = p.getCodec().readTree(p);

    if (!node.isInt()) {
      // Reject anything that isn't a JSON integer token.
      // That means: no strings, no floats, no booleans, no null.
      throw JsonMappingException.from(p, "Expected an integer number");
    }

    return node.intValue();
  }
}

Usage:

import com.fasterxml.jackson.databind.annotation.JsonDeserialize;

public record CreateOrderRequest(
    @JsonDeserialize(using = StrictIntDeserializer.class)
    Integer count
) {}

This guarantees count is a real JSON integer (not a string or float).

Step 3) Money fields: choose one representation and enforce it

Money is where “lenient” becomes dangerous.

You have two sane options:

Option A: represent money as string (recommended for many APIs)

client sends "amount": "12.34"
you parse to BigDecimal with your own rules (scale, rounding, max value)

Option B: represent money as integer minor units

client sends "amountCents": 1234
you store and compute in integers

Here’s a strict BigDecimal deserializer for Option A:

import com.fasterxml.jackson.core.JsonParser;
import com.fasterxml.jackson.databind.DeserializationContext;
import com.fasterxml.jackson.databind.JsonDeserializer;
import com.fasterxml.jackson.databind.JsonMappingException;
import com.fasterxml.jackson.databind.JsonNode;

import java.io.IOException;
import java.math.BigDecimal;

public class StrictBigDecimalStringDeserializer extends JsonDeserializer<BigDecimal> {

  @Override
  public BigDecimal deserialize(JsonParser p, DeserializationContext ctxt) throws IOException {
    JsonNode node = p.getCodec().readTree(p);

    if (!node.isTextual()) {
      throw JsonMappingException.from(p, "Expected a decimal string like \"12.34\"");
    }

    String raw = node.textValue();
    if (raw == null || raw.isBlank()) {
      throw JsonMappingException.from(p, "Amount must not be blank");
    }

    // Example rule: only digits + optional '.' + up to 2 decimals
    if (!raw.matches("^\\d+(\\.\\d{1,2})?$")) {
      throw JsonMappingException.from(p, "Amount format must be like \"12\" or \"12.34\"");
    }

    return new BigDecimal(raw);
  }
}

Usage:

import com.fasterxml.jackson.databind.annotation.JsonDeserialize;
import java.math.BigDecimal;

public record CreatePaymentRequest(
    @JsonDeserialize(using = StrictBigDecimalStringDeserializer.class)
    BigDecimal amount
) {}

Now "amount": 12.34 (number) fails, and "amount": "12.3400" fails if you require max 2 decimals.

Step 4) Make error responses consistent (so clients can handle them)

Strict parsing is only pleasant if clients get a predictable response.

A minimal error envelope:

{
  "status": 400,
  "error": "invalid.json",
  "message": "Malformed JSON or invalid field type",
  "details": [
    { "field": null, "reason": "Expected an integer number" }
  ]
}

You can implement this via @RestControllerAdvice handling HttpMessageNotReadableException (the exception Spring throws for JSON parse/type issues).

import jakarta.servlet.http.HttpServletRequest;
import org.springframework.http.ResponseEntity;
import org.springframework.http.converter.HttpMessageNotReadableException;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;

import java.util.List;

@RestControllerAdvice
public class JsonErrorHandler {

  @ExceptionHandler(HttpMessageNotReadableException.class)
  public ResponseEntity<ApiErrorResponse> handleNotReadable(
      HttpMessageNotReadableException ex,
      HttpServletRequest req
  ) {
    ApiErrorResponse body = ApiErrorResponse.of(
        400,
        "invalid.json",
        "Malformed JSON or invalid field type",
        req.getRequestURI(),
        null,
        List.of(ApiErrorDetail.of(null, rootCauseMessage(ex)))
    );
    return ResponseEntity.badRequest().body(body);
  }

  private static String rootCauseMessage(Throwable t) {
    Throwable cur = t;
    while (cur.getCause() != null) cur = cur.getCause();
    String msg = cur.getMessage();
    return (msg == null || msg.isBlank()) ? cur.getClass().getSimpleName() : msg;
  }
}

(If you already have a global error envelope, plug this into it.)

Step 5) Lock it with tests

This is important: strictness tends to “drift” over time when someone changes ObjectMapper settings.

Here’s a small @WebMvcTest that ensures wrong types fail:

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.context.annotation.Import;
import org.springframework.http.MediaType;
import org.springframework.test.web.servlet.MockMvc;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;

@WebMvcTest(PaymentController.class)
@Import({StrictJacksonConfig.class, JsonErrorHandler.class})
class StrictJsonTest {

  @Autowired MockMvc mvc;

  @Test
  void stringInsteadOfInt_shouldFail() throws Exception {
    String json = "{\"count\": \"10\"}";

    mvc.perform(post("/api/payments")
            .contentType(MediaType.APPLICATION_JSON)
            .content(json))
        .andExpect(status().isBadRequest())
        .andExpect(jsonPath("$.error").value("invalid.json"));
  }
}

Practical tips (what I wish I knew earlier)

Don’t return JPA entities directly from controllers — it mixes serialization concerns with persistence proxies and can trigger lazy loading.
Decide your money strategy early: decimal strings vs minor units.
Be explicit about unknown fields: failing fast saves a lot of production debugging.
If your consumers are internal services, strict JSON is even more valuable because you can enforce contracts as code.

Wrap-up

A strict JSON parser is a contract enforcer.

Once you tighten your deserialization rules:

you catch client mistakes instantly
you reduce data corruption risks
you simplify debugging (“the error tells you exactly what’s wrong”)

A Boring Error Format Is a Feature: Building a Consistent Error Envelope in Spring Boot

Thellu — Sun, 22 Feb 2026 17:55:15 +0000

When APIs grow, error handling usually becomes… creative:

sometimes a plain message string
sometimes a Spring default HTML error page
sometimes stack traces leak into JSON
validation errors look totally different from business errors
your frontend has to handle 7 shapes of “error”

A consistent error envelope is not “nice to have”. It’s a contract.

This post shows a pragmatic approach to implement a predictable error format in Spring Boot, covering:

Bean Validation errors (400)
JSON parse/type errors (400)
Custom business errors (409/422/etc.)
Not found (404)
A safe fallback (500)
A trace ID you can grep in logs
MockMvc tests so it stays consistent forever

The error envelope (contract)

Here’s a shape that’s boring—and that’s exactly why it works:

{
  "timestamp": "2026-02-22T18:20:31.123Z",
  "status": 400,
  "error": "invalid.request",
  "message": "Request validation failed",
  "path": "/api/users",
  "traceId": "9f2c1f0b1d1a4d0f",
  "details": [
    { "field": "email", "reason": "must be a well-formed email address" },
    { "field": "age", "reason": "must be greater than or equal to 18" }
  ]
}

Notes:

error: stable machine-readable code (great for FE)
message: human-readable summary
details: optional list for per-field/per-issue reasons
traceId: helps correlate client errors ↔ server logs quickly

Step 1) Define the response model

Use a small DTO (records work great):

import java.time.Instant;
import java.util.List;

public record ApiErrorResponse(
    Instant timestamp,
    int status,
    String error,
    String message,
    String path,
    String traceId,
    List<ApiErrorDetail> details
) {
  public static ApiErrorResponse of(
      int status,
      String error,
      String message,
      String path,
      String traceId,
      List<ApiErrorDetail> details
  ) {
    return new ApiErrorResponse(Instant.now(), status, error, message, path, traceId, details);
  }
}

public record ApiErrorDetail(String field, String reason) {
  public static ApiErrorDetail of(String field, String reason) {
    return new ApiErrorDetail(field, reason);
  }
}

Step 2) Add a traceId (simple and production-friendly)

If you already have a request ID from a gateway, reuse it. Otherwise, generate one.

import jakarta.servlet.FilterChain;
import jakarta.servlet.ServletException;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import org.slf4j.MDC;
import org.springframework.stereotype.Component;
import org.springframework.web.filter.OncePerRequestFilter;

import java.io.IOException;
import java.util.UUID;

@Component
public class TraceIdFilter extends OncePerRequestFilter {

  public static final String TRACE_ID = "traceId";
  private static final String HEADER = "X-Trace-Id";

  @Override
  protected void doFilterInternal(
      HttpServletRequest request,
      HttpServletResponse response,
      FilterChain filterChain
  ) throws ServletException, IOException {

    String traceId = request.getHeader(HEADER);
    if (traceId == null || traceId.isBlank()) {
      traceId = UUID.randomUUID().toString().replace("-", "").substring(0, 16);
    }

    MDC.put(TRACE_ID, traceId);
    response.setHeader(HEADER, traceId);

    try {
      filterChain.doFilter(request, response);
    } finally {
      MDC.remove(TRACE_ID);
    }
  }
}

Now every log line can include %X{traceId} in your logging pattern.

Step 3) Create a single place for all exception mapping

Use @RestControllerAdvice. If you already extend ResponseEntityExceptionHandler, you can override Spring’s default handlers too.

import jakarta.servlet.http.HttpServletRequest;
import jakarta.validation.ConstraintViolationException;
import org.slf4j.MDC;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.http.converter.HttpMessageNotReadableException;
import org.springframework.validation.FieldError;
import org.springframework.web.bind.MethodArgumentNotValidException;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;
import org.springframework.web.method.annotation.MethodArgumentTypeMismatchException;

import java.util.List;

import static java.util.Collections.emptyList;

@RestControllerAdvice
public class GlobalExceptionHandler {

  private static String traceId() {
    String v = MDC.get(TraceIdFilter.TRACE_ID);
    return (v == null || v.isBlank()) ? null : v;
  }

  @ExceptionHandler(MethodArgumentNotValidException.class)
  public ResponseEntity<ApiErrorResponse> handleMethodArgumentNotValid(
      MethodArgumentNotValidException ex,
      HttpServletRequest req
  ) {
    List<ApiErrorDetail> details = ex.getBindingResult().getAllErrors().stream()
        .map(err -> {
          if (err instanceof FieldError fe) {
            return ApiErrorDetail.of(fe.getField(), fe.getDefaultMessage());
          }
          return ApiErrorDetail.of(null, err.getDefaultMessage());
        })
        .toList();

    ApiErrorResponse body = ApiErrorResponse.of(
        400,
        "invalid.request",
        "Request validation failed",
        req.getRequestURI(),
        traceId(),
        details
    );
    return ResponseEntity.badRequest().body(body);
  }

  @ExceptionHandler(ConstraintViolationException.class)
  public ResponseEntity<ApiErrorResponse> handleConstraintViolation(
      ConstraintViolationException ex,
      HttpServletRequest req
  ) {
    List<ApiErrorDetail> details = ex.getConstraintViolations().stream()
        .map(v -> ApiErrorDetail.of(
            v.getPropertyPath() == null ? null : v.getPropertyPath().toString(),
            v.getMessage()
        ))
        .toList();

    ApiErrorResponse body = ApiErrorResponse.of(
        400,
        "invalid.request",
        "Constraint validation failed",
        req.getRequestURI(),
        traceId(),
        details
    );
    return ResponseEntity.badRequest().body(body);
  }

  @ExceptionHandler(HttpMessageNotReadableException.class)
  public ResponseEntity<ApiErrorResponse> handleNotReadable(
      HttpMessageNotReadableException ex,
      HttpServletRequest req
  ) {
    ApiErrorResponse body = ApiErrorResponse.of(
        400,
        "invalid.json",
        "Malformed JSON or invalid field type",
        req.getRequestURI(),
        traceId(),
        List.of(ApiErrorDetail.of(null, rootCauseMessage(ex)))
    );
    return ResponseEntity.badRequest().body(body);
  }

  @ExceptionHandler(MethodArgumentTypeMismatchException.class)
  public ResponseEntity<ApiErrorResponse> handleTypeMismatch(
      MethodArgumentTypeMismatchException ex,
      HttpServletRequest req
  ) {
    String field = ex.getName();
    ApiErrorResponse body = ApiErrorResponse.of(
        400,
        "invalid.request",
        "Invalid value for parameter",
        req.getRequestURI(),
        traceId(),
        List.of(ApiErrorDetail.of(field, ex.getMessage()))
    );
    return ResponseEntity.badRequest().body(body);
  }

  // Example custom app exceptions
  @ExceptionHandler(NotFoundException.class)
  public ResponseEntity<ApiErrorResponse> handleNotFound(
      NotFoundException ex,
      HttpServletRequest req
  ) {
    ApiErrorResponse body = ApiErrorResponse.of(
        404,
        "not.found",
        ex.getMessage(),
        req.getRequestURI(),
        traceId(),
        emptyList()
    );
    return ResponseEntity.status(HttpStatus.NOT_FOUND).body(body);
  }

  @ExceptionHandler(ConflictException.class)
  public ResponseEntity<ApiErrorResponse> handleConflict(
      ConflictException ex,
      HttpServletRequest req
  ) {
    ApiErrorResponse body = ApiErrorResponse.of(
        409,
        "conflict",
        ex.getMessage(),
        req.getRequestURI(),
        traceId(),
        emptyList()
    );
    return ResponseEntity.status(HttpStatus.CONFLICT).body(body);
  }

  // Fallback: never leak stack traces to clients
  @ExceptionHandler(Exception.class)
  public ResponseEntity<ApiErrorResponse> handleUnexpected(
      Exception ex,
      HttpServletRequest req
  ) {
    ApiErrorResponse body = ApiErrorResponse.of(
        500,
        "internal.error",
        "Unexpected server error",
        req.getRequestURI(),
        traceId(),
        emptyList()
    );
    return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(body);
  }

  private static String rootCauseMessage(Throwable t) {
    Throwable cur = t;
    while (cur.getCause() != null) cur = cur.getCause();
    String msg = cur.getMessage();
    return (msg == null || msg.isBlank()) ? cur.getClass().getSimpleName() : msg;
  }
}

Minimal custom exceptions:

public class NotFoundException extends RuntimeException {
  public NotFoundException(String message) { super(message); }
}

public class ConflictException extends RuntimeException {
  public ConflictException(String message) { super(message); }
}

Step 4) Example controller to see it in action

import jakarta.validation.constraints.Email;
import jakarta.validation.constraints.Min;
import jakarta.validation.constraints.NotBlank;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/api/users")
public class UserController {

  @PostMapping
  public UserDto create(@RequestBody CreateUserRequest req) {
    if ("taken@example.com".equalsIgnoreCase(req.email())) {
      throw new ConflictException("Email already exists");
    }
    return new UserDto("u_123", req.email());
  }

  @GetMapping("/{id}")
  public UserDto get(@PathVariable String id) {
    throw new NotFoundException("User not found: " + id);
  }

  public record CreateUserRequest(
      @NotBlank String name,
      @Email String email,
      @Min(18) int age
  ) {}

  public record UserDto(String id, String email) {}
}

Step 5) Tests: lock the contract with MockMvc

These tests prevent future refactors from accidentally changing your error shape.

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.context.annotation.Import;
import org.springframework.http.MediaType;
import org.springframework.test.web.servlet.MockMvc;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;

@WebMvcTest(UserController.class)
@Import({GlobalExceptionHandler.class, TraceIdFilter.class})
class ErrorEnvelopeTest {

  @Autowired MockMvc mvc;

  @Test
  void validationErrors_returnConsistentEnvelope() throws Exception {
    String json = "{"
        + "\"name\": \"\","
        + "\"email\": \"not-an-email\","
        + "\"age\": 10"
        + "}";

    mvc.perform(post("/api/users")
            .contentType(MediaType.APPLICATION_JSON)
            .content(json))
        .andExpect(status().isBadRequest())
        .andExpect(jsonPath("$.status").value(400))
        .andExpect(jsonPath("$.error").value("invalid.request"))
        .andExpect(jsonPath("$.path").value("/api/users"))
        .andExpect(jsonPath("$.details").isArray())
        .andExpect(jsonPath("$.details.length()").value(3));
  }

  @Test
  void malformedJson_returnInvalidJsonEnvelope() throws Exception {
    String json = "{ \"name\": \"a\", \"email\": \"x@\", \"age\": }";

    mvc.perform(post("/api/users")
            .contentType(MediaType.APPLICATION_JSON)
            .content(json))
        .andExpect(status().isBadRequest())
        .andExpect(jsonPath("$.error").value("invalid.json"))
        .andExpect(jsonPath("$.details").isArray());
  }

  @Test
  void notFound_return404Envelope() throws Exception {
    mvc.perform(get("/api/users/does-not-exist"))
        .andExpect(status().isNotFound())
        .andExpect(jsonPath("$.status").value(404))
        .andExpect(jsonPath("$.error").value("not.found"));
  }
}

Practical tips (the stuff that saves you later)

Keep error codes stable (invalid.request, not.found, conflict) even if messages change.
Don’t return stack traces to clients. Log them with traceId.
Don’t return JPA entities directly from controllers (unrelated issue, but it breaks predictability fast).
If your API is public, add these response schemas to your OpenAPI so consumers rely on them.

Wrap-up

A consistent error envelope is a boring contract—and that’s a feature.

Once you standardize it:

frontend becomes simpler
logs become searchable
incidents become faster to triage
your API feels “professional” immediately

`getReferenceById()` Isn’t “No-DB”: What It Really Does in JPA (and When to Use It)

Thellu — Mon, 02 Feb 2026 16:51:54 +0000

If you’ve used Spring Data JPA long enough, you’ve probably seen this advice:

“Use getReferenceById() to avoid a database query.”

It’s not wrong — but it’s also not the full story.

getReferenceById() (backed by EntityManager.getReference()) usually returns a lazy proxy. That proxy can avoid an immediate SELECT, but it can also surprise you later with extra queries, unexpected exceptions, or weird JSON output.

This post explains what it actually does, when it hits the DB, and the safe patterns to use it.

What `getReferenceById()` actually returns

When you call:

User user = userRepository.getReferenceById(id);

you usually get a proxy object (Hibernate proxy) that:

knows the entity type (User)
remembers the id
does not necessarily load the row immediately
will load the entity later, if/when you touch a non-id property

Think of it like: “I promise there’s a User with this id — I’ll fetch it only if you ask for details.”

When it doesn’t query the database

In many write-only use cases, you only need a reference to set a relationship.

Example: create a Payment pointing to an existing User, without loading the User.

@Transactional
public void createPayment(Long userId, BigDecimal amount) {
  User userRef = userRepository.getReferenceById(userId);

  Payment p = new Payment();
  p.setUser(userRef);
  p.setAmount(amount);

  paymentRepository.save(p); // often no SELECT for User
}

If you never access userRef.getName() / userRef.getEmail() etc., Hibernate can persist Payment using the FK (user_id) without loading the User.

✅ This is the best use case for getReferenceById().

When it will query the database

1) Accessing any non-id field

User userRef = repo.getReferenceById(id);

// Triggers SELECT (lazy initialization)
String name = userRef.getName();

Even calling toString() can trigger a load if your toString() prints fields.

2) Serializing entity proxies (e.g., returning entities from controllers)

If you return JPA entities directly from a REST controller, your JSON serializer (Jackson) may try to read fields → which triggers lazy loading → which triggers queries.

Sometimes it becomes:

N+1 queries
LazyInitializationException (if outside transaction)
weird proxy metadata in JSON

Rule: Do not return entities directly. Return DTOs.

The “surprise exception” people don’t expect

Entity not found… but only later

Unlike findById(), which checks immediately, a reference may fail when initialized.

User userRef = repo.getReferenceById(999L); // no immediate SELECT

// Later...
userRef.getName(); // may throw EntityNotFoundException at this moment

So your code might look fine during the write, then explode at a random later point when something touches the proxy.

`getReferenceById()` vs `findById()` (practical difference)

`findById(id)`

Executes a SELECT immediately
Returns Optional<T>
You know right away whether it exists
Best for read paths, validation, business decisions

`getReferenceById(id)`

Returns a proxy reference (usually no immediate SELECT)
Existence is not verified immediately
Best for write paths when you only need an FK reference

Safe patterns you can copy

✅ Pattern A: “FK-only write path”

Use reference when you only need the FK and don’t care about reading the parent.

@Transactional
public void addItem(Long orderId, String sku) {
  Order orderRef = orderRepository.getReferenceById(orderId);

  OrderItem item = new OrderItem();
  item.setOrder(orderRef);
  item.setSku(sku);

  orderItemRepository.save(item);
}

If the orderId is invalid, the DB may reject it via FK constraint on flush/commit.

✅ Pattern B: “Validate first, then reference”

If you need a friendly error message, validate existence first.

@Transactional
public void addItem(Long orderId, String sku) {
  if (!orderRepository.existsById(orderId)) {
    throw new IllegalArgumentException("Order not found: " + orderId);
  }
  Order orderRef = orderRepository.getReferenceById(orderId);

  OrderItem item = new OrderItem();
  item.setOrder(orderRef);
  item.setSku(sku);

  orderItemRepository.save(item);
}

(Yes, that’s an extra query — but it’s explicit and predictable.)

✅ Pattern C: map to DTOs (avoid proxy serialization traps)

Never return entities directly:

@GetMapping("/users/{id}")
public UserDto getUser(@PathVariable Long id) {
  User user = userRepository.findById(id).orElseThrow();
  return new UserDto(user.getId(), user.getName());
}

Common foot-guns (learn once, avoid forever)

❌ 1) Calling `getReferenceById()` and then logging fields

log.info("User name={}", userRef.getName()); // triggers SELECT

❌ 2) Using Lombok `@Data` on entities with lazy relations

Generated toString(), equals(), hashCode() can touch lazy fields and cause loading.

Tip: For entities, prefer:

@Getter/@Setter
carefully controlled toString()
equals/hashCode based on immutable identifiers (or the id once assigned), with caution

❌ 3) Using reference outside a transaction and accidentally initializing it

This is where LazyInitializationException shows up.

How to prove what’s happening (simple debugging trick)

Turn on SQL logging in dev:

spring.jpa.show-sql=true
logging.level.org.hibernate.SQL=DEBUG

Then compare:

findById() → you’ll see immediate SELECT
getReferenceById() → you’ll often see no SQL until a getter is called

Rule of thumb

If you remember only one thing, remember this:

Read path: use findById() (or a query/DTO projection)
Write path (FK-only): use getReferenceById()
Never: return JPA entities directly from REST endpoints

Why `@Transactional` “Doesn’t Work” in Spring: 7 Proxy Gotchas (and Fixes)

Thellu — Sun, 28 Dec 2025 18:22:43 +0000

You add @Transactional, expect a rollback… and the data still commits.

Most of the time, Spring transactions are working exactly as designed — it’s just that your code never actually enters a transactional boundary. The reason is simple:

Spring usually applies transactions via AOP proxies.

If your call bypasses the proxy, the transaction advice never runs.

Here are 7 common gotchas I see in real projects, plus practical fixes.

0) Quick mental model: where transactions actually start

With proxy-based AOP, a transaction starts when:

A Spring-managed bean method is called
and that call goes through the proxy
and the method has transactional metadata (@Transactional)

So the key question when debugging is always:

“Did this method call go through the Spring proxy?”

1) Self-invocation: calling your own method bypasses the proxy

This is the #1 reason people say “transaction didn’t work”.

@Service
public class OrderService {

  public void placeOrder() {
    saveOrder(); // self-invocation -> no proxy -> @Transactional not applied
  }

  @Transactional
  public void saveOrder() {
    // write to DB
    throw new RuntimeException("boom"); // you expect rollback
  }
}

What happens?

placeOrder() calls saveOrder() directly on this. No proxy involved. No transaction.

✅ Fix options (pick one):

Fix A (recommended): move transactional method to another bean

@Service
public class OrderWriter {
  @Transactional
  public void saveOrder() { ... }
}

@Service
public class OrderService {
  private final OrderWriter writer;
  public OrderService(OrderWriter writer) { this.writer = writer; }

  public void placeOrder() {
    writer.saveOrder(); // goes through proxy
  }
}

Fix B: use TransactionTemplate for programmatic transactions

@Service
public class OrderService {
  private final TransactionTemplate tx;

  public OrderService(PlatformTransactionManager tm) {
    this.tx = new TransactionTemplate(tm);
  }

  public void placeOrder() {
    tx.executeWithoutResult(status -> {
      // write to DB
      if (somethingBad()) throw new RuntimeException("boom");
    });
  }
}

2) Method visibility: non-public methods often won’t be transactional

By default (proxy-based AOP), Spring typically only applies @Transactional to public methods.

@Service
public class BillingService {

  @Transactional
  void charge() { // package-private: often ignored
    ...
  }
}

✅ Fix: make the transactional boundary public, or switch to AspectJ weaving (advanced).

@Transactional
public void charge() { ... }

3) `final` classes/methods: proxies can’t override them

If Spring uses CGLIB class-based proxies, final prevents overriding.

@Service
public final class PaymentService {

  @Transactional
  public void pay() { ... } // cannot be proxied if class/method is final
}

✅ Fix:

remove final, or
use interface-based proxies (JDK proxy) and call through the interface, but final methods still can’t be advised.

In practice: avoid final on Spring service classes/methods that need AOP.

4) Checked exceptions don’t rollback by default

By default, Spring rolls back on:

RuntimeException
Error

…but not on checked exceptions.

@Transactional
public void ship() throws Exception {
  // write DB
  throw new Exception("checked"); // by default: transaction may COMMIT
}

✅ Fix: configure rollback rules explicitly.

@Transactional(rollbackFor = Exception.class)
public void ship() throws Exception {
  ...
}

Or throw a runtime exception intentionally (be consistent in your codebase).

5) Catching exceptions (and swallowing them) commits the transaction

This one is sneaky.

@Transactional
public void updateProfile() {
  try {
    // write to DB
    riskyOperation();
  } catch (Exception e) {
    // log and swallow
  }
  // method ends normally -> transaction commits
}

✅ Fix options:

Fix A: rethrow

catch (Exception e) {
  throw e;
}

Fix B: mark rollback-only

catch (Exception e) {
  TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
}

Use rollback-only sparingly — rethrowing is often clearer.

6) `@PostConstruct` / constructor calls: proxy isn’t ready yet

If you call transactional methods during bean initialization, you can bypass the proxy lifecycle.

@Service
public class WarmUpService {

  @PostConstruct
  public void init() {
    warmUp(); // often not transactional the way you expect
  }

  @Transactional
  public void warmUp() { ... }
}

✅ Fix: run warmup after context is fully ready:

ApplicationReadyEvent
CommandLineRunner
scheduling after startup

@Component
public class WarmUpRunner implements ApplicationRunner {
  private final WarmUpService svc;
  public WarmUpRunner(WarmUpService svc) { this.svc = svc; }

  @Override
  public void run(ApplicationArguments args) {
    svc.warmUp(); // goes through proxy
  }
}

7) Async / new threads: transactions are thread-bound

A transaction is bound to the current thread. If you start a new thread, it won’t share the same transaction context.

@Transactional
public void process() {
  // write in tx
  CompletableFuture.runAsync(() -> {
    // NOT in the same tx
    // writes here are separate
  });
}

✅ Fix patterns:

Make the async method start its own transaction
Or use messaging / outbox pattern for consistency
Or redesign: keep DB transaction small, push slow work out of it

A quick debugging checklist

When you suspect “transaction didn’t work”, check these in order:

Is the method public?
Is it called from another bean (through proxy), not this.?
Any final class/method involved?
Did you throw a runtime exception? Or a checked exception?
Did you catch and swallow exceptions?
Was it invoked during initialization (@PostConstruct)?
Any async/thread boundaries?

Also helpful: enable transaction logs (for Spring Boot):

logging.level.org.springframework.transaction=DEBUG
logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManager=DEBUG

You should see logs like “Creating new transaction” / “Rolling back” / “Committing”.

Recommended rule of thumb

If you want fewer surprises:

Put transaction boundaries on public service methods
Keep them short
Avoid calling transactional methods inside the same class
Don’t mix DB transactions with slow network calls
Use TransactionTemplate if you need explicit control

The Real Initialization Order of Java Classes (And a Subtle Pitfall)

Thellu — Sun, 07 Dec 2025 19:04:31 +0000

The Real Initialization Order of Java Classes (And a Subtle Pitfall)

Most Java developers “know” the basic initialization order of a class:

Call the base class constructor (and repeat this up the inheritance chain)
Initialize member fields in the order of declaration
Execute the body of the class constructor

This mental model works in many cases—but it’s incomplete.

In some situations, especially when inheritance and overridden methods are involved, this understanding can lead to very surprising behavior.

Let’s look at a concrete example.

A Surprising Example

Consider the following code:

class Animal {

    public void walk() {
        System.out.println("Animal.walk()");
    }

    Animal() {
        System.out.println("Animal() before walk()");
        walk();
        System.out.println("Animal() after walk()");
    }
}

class Cat extends Animal {
    private int step = 100;

    @Override
    public void walk() {
        System.out.println("Cat.walk(), step = " + step);
    }

    Cat(int step) {
        this.step = step;
        System.out.println("Cat.Cat(), step = " + step);
    }
}

public class Main {
    public static void main(String[] args) {
        new Cat(500);
    }
}

At a glance, you might expect the output to use step = 100 at least once, since that’s the field’s default value in Cat.

But here’s what actually gets printed:

Animal() before walk()
Cat.walk(), step = 0
Animal() after walk()
Cat.Cat(), step = 500

Key observations:

Animal’s constructor calls walk().
Because walk() is overridden in Cat, Cat.walk() is invoked.
But when Cat.walk() is called, step is 0, not 100, and not 500.

So what’s going on?

What Actually Happens During Initialization

To understand this, we need a more accurate mental model of Java’s object initialization process.

The real steps are roughly:

Memory allocation & zeroing When you create a new object (e.g. new Cat(500)), the JVM:
- Allocates memory for the full object (including Animal and Cat parts)
- Initializes that memory to binary zero
  - For primitives (int, long, etc.), that means 0
  - For references, that means null

At this moment, step is 0.

Base class constructor chain

Before Cat’s constructor body runs, Java must call the base class constructor(s):
- Animal() runs first.
- Inside Animal() we call walk().
- Due to dynamic dispatch, Cat.walk() is called even though we’re inside Animal’s constructor.
- But remember: Cat’s own fields haven’t been initialized yet, so step is still 0.
Field initialization of the current class

After all base constructors complete, Java initializes the fields declared in Cat, in the order they appear:
- private int step = 100; runs here.
- Now step becomes 100.
Subclass constructor body

Finally, the body of Cat(int step) executes:
- this.step = step; sets step to 500.
- Then we print Cat.Cat(), step = 500.

So the full timeline for step is:

Allocated and zeroed → step = 0
Animal() calls walk() → prints step = 0
Field initializer runs → step = 100
Cat constructor body runs → step = 500

That’s why you see step = 0 in the output.

Why This Is Dangerous

This behavior leads to a subtle but important rule:

Never rely on subclass state inside a base class constructor.

Because:

The base class constructor can (and often does) use virtual methods.
Those methods might be overridden in subclasses.
If they are, they might access fields that are not initialized yet.
This can cause incorrect behavior that’s very hard to detect and debug.

In our example, Animal() “innocently” calls walk(), but that ends up invoking Cat.walk(), which uses step before it’s properly initialized.

Safe Practices for Constructors

To avoid this category of bugs, you can follow these guidelines:

1. Avoid calling overridable methods in constructors

Don’t call methods that can be overridden (public, protected, or package-private non-final methods).
If you must call a method from the constructor, make it private or final to prevent overriding.

2. Base class constructors should only use base-class state

Use only fields defined in the base class.
Don’t “assume” anything about subclass fields or behavior.

3. Initialize all fields before using them

Be careful not to pass this to other objects from inside your constructor if they might immediately call overridable methods on it.

4. Final methods in base classes are safe

The only virtual methods that are “safe” to call in a constructor are:

final methods in the base class

Because they cannot be overridden, the behavior is fixed and can’t accidentally depend on uninitialized subclass state.

How I Reduced My Oracle SQL Query Time from 110s to 1s

Thellu — Tue, 18 Nov 2025 20:25:27 +0000

Recently, I ran into a performance issue while writing an Oracle SQL
query.
The execution time was shockingly slow --- about 110 seconds for the
whole query, with each sub-query taking around 18 seconds.

Here's a simplified version of one of the SQL blocks (several nearly
identical blocks were combined using UNION ALL):

select
    'A' as type,
    count(adl.is_attend) as count,
    round(
        sum(case when adl.is_attend = 1 then 1 else 0 end)
        / count(adl.is_attend), 2
    ) * 100 as rate
from attendance adl
inner join (
        select deptId
        from department
        start with deptId = '...'
        connect by up_daptId = prior deptId
    ) nbd on adl.deptId = nbd.deptId
where 
    to_date(adl.date,'yyyy-MM-dd') >= to_date(#{begin_date},'yyyy-MM-dd')
    and to_date(adl.date,'yyyy-MM-dd') <= to_date(#{end_date},'yyyy-MM-dd');

#{begin_date} and #{end_date} are backend parameters passed
dynamically.

Since this block is repeated multiple times with only minor differences,
the total runtime quickly stacked up to over 100 seconds.

Why Was It So Slow?

1. Huge amount of data

The attendance table contains 13+ million rows.\
Even a simple full table scan takes close to 20 seconds.

2. Recursive join

The query joins the department table using Oracle's hierarchical
query:

start with ... connect by ...

This expands to all sub-departments under a given department, which is
computationally expensive.

⚡ Optimization Step 1 --- Indexing the Join Key

First of all, the problem of data volume is unsolvable. It is impossible for us to say that a certain piece of data is directly discarded. Moreover, our where condition has already limited the time, so there is actually a certain limit on the data volume. Therefore, the first idea of optimization is on Join:

Recursive Join is a very time-consuming operation, so we can directly think of building an index on deptId-in fact.

This is the correct idea, adding an index immediately reduced the execution time:

18 seconds → 2 seconds

⚡ Optimization Step 2 --- Removing `to_date` in the WHERE Clause (With Caution)

Calling to_date() on a column disables index usage:

to_date(adl.date,'yyyy-MM-dd') >= ...

The to_date function is used when the date is limited. In fact, when only comparing the year, month, and day, we can directly not use this function for string comparison. This is because Oracle SQL's Data Priority will implicitly convert low-priority strings to date formats. Here, through implicit conversion, the running time can be continuously optimized, from 2S to 1S.

But note, this is risky - first, implicit data type conversion may have a negative impact on performance (of course here is a positive); also, implicit conversion may produce strange results. Depending on the value of the NLS_DATE_FORMAT parameter.

When converting a datetime value to text via an implicit conversion or an explicit conversion that does not specify a format model, the format model is defined by one of the globalization session parameters, namely NLS_DATE_FORMAT, NLS_TIMESTAMP_FORMAT, or NLS_TIMESTAMP_TZ_FORMAT.

For example, the default value of the NLS_DATE_FORMAT setting is 'DD-MON-RR' two-digit year, so the century time may be lost when the date is converted to a string, and replaced by 1900 or 2000 when converted back to a date based on the decade value; and assuming that the original time has some minutes and seconds, this data will also be lost.

In conclusion, different parameters may have different results.

So, considering that the optimization of Solution 2 is not necessary, I still keep the date function.

✅ Final Result

After applying only the safe optimization (indexing):

Whole query time: 110s → 10s
Each SQL block: 18s → 2s

With date optimization (not used in production):

Each block: ~1s

Understanding MySQL Backup Consistency: A Practical Example

Thellu — Sun, 26 Oct 2025 19:49:18 +0000

This post documents the knowledge I’ve gained while learning how to perform data backups in MySQL. It serves both as a learning note and a reference for future use.

Objective

When performing a logical backup (for example, using mysqldump), ensuring data consistency is critical — especially in an active transactional environment.

This post explains how to use MySQL’s Repeatable Read isolation level, consistent snapshots, and savepoints to achieve that.

Example Code

Let’s look directly at the example SQL script:

Q1: SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
Q2: START TRANSACTION WITH CONSISTENT SNAPSHOT;
/* other tables */
Q3: SAVEPOINT sp;
/* Time 1 */
Q4: SHOW CREATE TABLE `t1`;
/* Time 2 */
Q5: SELECT * FROM `t1`;
/* Time 3 */
Q6: ROLLBACK TO SAVEPOINT sp;
/* Time 4 */
/* other tables */

Step-by-Step Explanation

Q1 — Set the Isolation Level

At the beginning of the backup process, explicitly set the Repeatable Read (RR) isolation level to ensure consistent reads across transactions.

Q2 — Start a Consistent Transaction

START TRANSACTION WITH CONSISTENT SNAPSHOT;

This statement ensures a consistent view (snapshot) of all tables at the moment it is executed.

Q3 — Create a Savepoint

Setting a savepoint (SAVEPOINT sp) allows rolling back to a specific point later in the transaction.

Q4 — Export Table Definition

Use SHOW CREATE TABLE t1; to capture the table structure.

Q5 — Export Table Data

Next, query all data from the table:

SELECT * FROM t1;

Q6 — Release Locks

Finally, ROLLBACK TO SAVEPOINT sp; rolls back to the savepoint, effectively releasing the MDL (Metadata Lock) on t1.

What Happens if a DDL Arrives Mid-Backup?

Let’s consider different timing scenarios if a DDL (for example, ALTER TABLE) is executed during the backup.

Time	Scenario	Outcome
Time 1 (before Q4)	DDL completes before the backup starts reading `t1`.	✅ No impact. The backup captures the structure after the DDL.
Time 2 (during Q4–Q5)	DDL occurs after `SHOW CREATE` but before data export.	❌ Error: `Table definition has changed, please retry transaction.` The backup (mysqldump) terminates.
Between Time 2 and Time 3	Backup holds an MDL read lock on `t1`.	⚠️ Binlog is blocked — replication delay until Q6 completes.
Time 4 and later	DDL executes after the MDL lock is released.	✅ No impact. Backup captures table structure before the DDL.

Summary

Use REPEATABLE READ + WITH CONSISTENT SNAPSHOT to maintain transactional consistency.
Use savepoints strategically to release locks without ending the transaction.
Be aware of DDL timing, which can affect replication and mysqldump behavior.

Reference

(1) https://time.geekbang.org/column/article/70215

Understanding Java Overloading & Static Dispatch

Thellu — Sun, 05 Oct 2025 15:56:04 +0000

1️⃣ Static Type vs. Actual (Runtime) Type

In Java, every variable has:

Static type (compile-time type) --- what the compiler sees and uses to check method calls.
Actual type (runtime type) --- the real class of the object stored in that variable.

Example:

Human man = new Man();

Human → static type\
Man → actual (runtime) type

Static type is fixed at compile time. Actual type is only known at
runtime.

2️⃣ Overloading Is Based on Static Type

Take this code:

public class StaticDispatch {
    static abstract class Human {}
    static class Man extends Human {}
    static class Woman extends Human {}

    public void sayHello(Human people) {
        System.out.println("hello,people");
    }

    public void sayHello(Man man) {
        System.out.println("hello,man");
    }

    public void sayHello(Woman woman) {
        System.out.println("hello,woman");
    }

    public static void main(String[] args) {
        Human man = new Man();
        Human woman = new Woman();
        StaticDispatch sr = new StaticDispatch();
        sr.sayHello(man);
        sr.sayHello(woman);
    }
}

Output:

hello,people
hello,people

Why?
Because overloading resolution happens at compile time --- the
compiler only sees that the variables man and woman are declared as
Human. It doesn't care that at runtime the actual objects are Man
and Woman.

If you want the compiler to choose the more specific overload, you must
cast:

sr.sayHello((Man) man);
sr.sayHello((Woman) woman);

Now the static types at the call site are Man and Woman, so the
specific overloads will be chosen.

3️⃣ Overload Resolution Priority

Sometimes, multiple overloaded methods can match. Java applies a
specific priority order to decide which one to use.

Let's look at a classic example:

public class A {
    public static void sayHi(Object arg)       { System.out.println("object"); }
    public static void sayHi(int arg)          { System.out.println("int"); }
    public static void sayHi(long arg)         { System.out.println("long"); }
    public static void sayHi(Character arg)    { System.out.println("Character"); }
    public static void sayHi(char arg)         { System.out.println("char"); }
    public static void sayHi(char... arg)      { System.out.println("char..."); }
    public static void sayHi(Serializable arg) { System.out.println("Serializable"); }

    public static void main(String[] args) {
        sayHi('a');
    }
}

Run with all methods

Output → char

Because 'a' is literally a char.

Comment out `sayHi(char)`

Output → int
Reason: 'a' can be promoted to its numeric value 97.

Comment out `sayHi(int)`

Output → long
Reason: widening: char -> int -> long.

Comment out `sayHi(long)`

Output → Character
Reason: autoboxing 'a' to Character.

Comment out `sayHi(Character)`

Output → Serializable
Reason: Character implements Serializable.

Comment out `sayHi(Serializable)`

Output → Object
Reason: autobox to Character then upcast to Object.

Comment out `sayHi(Object)`

Output → char...
Reason: fallback to varargs.

👉 Priority summary:

Primitive exact match >
Widening primitive conversion >
Autoboxing to wrapper >
Autoboxing to implemented interfaces >
Autoboxing to Object >
Varargs

4️⃣ Why It Matters

This might seem academic, but understanding overloading resolution
and the compile-time vs runtime type distinction helps you:

Avoid surprising method calls.
Write cleaner APIs (be careful with overloads that can cause ambiguity).
Debug confusing NoSuchMethodError or ambiguous method errors.

For interview prep or deep JVM knowledge, this topic often comes up ---
especially the static vs runtime type concept and how overload
resolution works.

⚡️ Key Takeaways

Overloading uses compile-time types. The JVM doesn't do dynamic dispatch for overloaded methods.
Casting affects overload resolution (because it changes the static type at the call site).
Autoboxing & varargs are fallback mechanisms with well-defined priority.
Be mindful with overloaded APIs --- too many similar signatures can cause unexpected calls.

💬 Have you encountered unexpected overload resolution in real projects
or interviews? Share your experiences below!

Understanding MySQL Backup with Consistent Snapshot and MDL Locks

Thellu — Sun, 14 Sep 2025 14:18:03 +0000

This post documents some key insights I learned while exploring how MySQL performs consistent backups. I wanted to capture this here for future reference — both for myself and for anyone else facing similar challenges.

Goal: Backup with Consistent Snapshot

When taking a logical backup (e.g., using mysqldump), we need a consistent view of the database to ensure the exported data is reliable and can be restored safely.

Here's the process I explored:

Q1: SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
Q2: START TRANSACTION WITH CONSISTENT SNAPSHOT;
/* other tables */
Q3: SAVEPOINT sp;
/* Time 1 */
Q4: SHOW CREATE TABLE `t1`;
/* Time 2 */
Q5: SELECT * FROM `t1`;
/* Time 3 */
Q6: ROLLBACK TO SAVEPOINT sp;
/* Time 4 */
/* other tables */

Step-by-Step Breakdown

Q1: Re-assert the isolation level to REPEATABLE READ to guarantee a consistent transaction view.
Q2: Start a transaction with WITH CONSISTENT SNAPSHOT. This ensures that all reads within this transaction will see a snapshot of the data as of this moment.
Q3: Set a savepoint. This will allow us to roll back later without ending the transaction.
Q4: Retrieve the table schema via SHOW CREATE TABLE.
Q5: Select and export the data.
Q6: Roll back to the savepoint, which releases the MDL (metadata lock) on t1.

This approach ensures that while the backup is running, we hold the necessary locks to maintain consistency but release them as early as possible to minimize replication delay.

DDL Arrival Scenarios

What happens if a DDL statement arrives while this backup process is running?

Time	What Happens	Scenario
Time 1 (Before Q4)	Backup captures the schema after DDL is applied.	✅ No impact — backup uses new schema.
Time 2 (After Q4, before Q5)	Table definition changed → Q5 fails.	❌ mysqldump terminates with error: `Table definition has changed, please retry transaction`.
Between Time 2 & 3	`mysqldump` holds MDL read lock, blocking DDL and binlog.	⚠️ Replication delay occurs until Q6 (rollback) is executed.
Time 4 (After Q6)	MDL lock is released, DDL can proceed.	✅ No impact — backup uses pre-DDL schema.

Key Takeaways

WITH CONSISTENT SNAPSHOT is crucial for creating a transaction-level consistent view.
Savepoints allow MDL locks to be released earlier, reducing replication lag.
Timing of incoming DDL statements matters — they can either be captured in the backup or cause the dump to fail.

Reference

This post is inspired by content from MYSQL Practice.

Intranet-Only Projects Pitfall (Maven and SVN)

Thellu — Sun, 31 Aug 2025 15:06:35 +0000

Recently, I had my very first experience working on a project that runs completely offline on an intranet. Since I had to figure out a lot of things from scratch, I decided to write down the issues I ran into — hopefully this saves someone else a few hours of frustration!

🛠 Maven Offline Mode Gotcha

Because of intranet security requirements, the project runs on a virtual machine that cannot access the Internet. This means we need to have all dependencies pre-downloaded and available locally.

While configuring pom.xml, IntelliJ IDEA kept throwing a strange error:

Cannot access maven-default-http-blocker (http://0.0.0.0/) in offline mode

At first, I tried enabling Maven's offline mode, as most blog posts suggested — but that didn’t help at all. After some digging, I realized it was actually a Maven version issue.

The version of Maven bundled with my IDEA (Maven 3.8+) includes the following configuration in settings.xml by default:

<mirror>
  <id>maven-default-http-blocker</id>
  <mirrorOf>external:http:*</mirrorOf>
  <name>Pseudo repository to mirror external repositories initially using HTTP.</name>
  <url>http://0.0.0.0/</url>
  <blocked>true</blocked>
</mirror>

This is Maven’s way of blocking external HTTP repositories for security reasons — to prevent man-in-the-middle attacks when downloading dependencies.

🔧 Solution

You have two main options:

Downgrade Maven to a version prior to 3.8, which doesn’t block HTTP by default.
If you want to keep using the bundled Maven, edit the settings.xml under \plugins\maven\lib\maven3\conf (inside your IDEA installation directory) and comment out the maven-default-http-blocker mirror.

Personally, I went with option 2. Just be aware that this weakens security since HTTP downloads are no longer blocked — make sure you trust your intranet repository.

📥 Importing Projects from SVN in IDEA

To make things more interesting, this project uses SVN instead of Git. Importing it into IntelliJ IDEA was straightforward but had one unexpected issue.

Like with Git, you can go to File → New → Project from Version Control, and then select Subversion (SVN) from the dropdown menu:

After entering the company’s SVN repository URL, IDEA will automatically fetch the project folders (source, tests, packages, etc.).

But… I hit another error:

Cannot run program “svn”: CreateProcess error=2

Turns out this happens because IDEA relies on the SVN command-line client, and if it isn’t installed locally, it just fails.

🔧 Solution

Re-run the SVN installer (.msi file), choose Modify, and make sure to install the Command Line Client Tools option:

After that, everything worked smoothly.

💡 Takeaways

Check Maven version early if you’re working in an offline environment — 3.8+ blocks HTTP repos by default.
Don’t forget the CLI tools when using SVN with IDEA — GUI integration depends on them.
Working in an intranet-only setup requires a bit more preparation, but once things are configured, development feels the same as online.

ThreadLocal in Java: Why You Must Call `remove()` in Thread Pools （AVOID OOM）

Thellu — Sun, 29 Jun 2025 13:01:28 +0000

If you're using ThreadLocal inside thread pools and not calling remove(), you're probably leaking memory. Here's why — and how to fix it.

Java’s ThreadLocal is often used to store data scoped to the current thread — things like database connections, user context, date formatters, etc. It’s incredibly convenient, but there’s a gotcha that trips up even experienced developers:

When used with thread pools, failing to call remove() can cause memory leaks and data leakage between tasks.

Let me show you what that looks like.

😌 The Safe Case: Manually Created Threads

public class ManualThreadExample {
    private static final ThreadLocal<String> threadLocal = new ThreadLocal<>();

    public static void main(String[] args) throws InterruptedException {
        Thread thread = new Thread(() -> {
            threadLocal.set("hello");
            System.out.println("ThreadLocal value: " + threadLocal.get());
            // No remove()
        });

        thread.start();
        thread.join();
    }
}

No big deal here. Even though we didn’t call remove(), once the thread exits, the whole thread (and its ThreadLocalMap) gets GC’d. So memory is cleaned up anyway.

💥 The Dangerous Case: Thread Pools

public class ThreadPoolLeakExample {
    private static final ThreadLocal<String> threadLocal = new ThreadLocal<>();
    private static final ExecutorService executor = Executors.newFixedThreadPool(1);

    public static void main(String[] args) {
        Runnable task1 = () -> {
            threadLocal.set("User A");
            System.out.println("Task 1: " + threadLocal.get());
            // Forgot to remove!
        };

        Runnable task2 = () -> {
            System.out.println("Task 2 (should be clean): " + threadLocal.get());
        };

        executor.execute(task1);
        executor.execute(task2);

        executor.shutdown();
    }
}

Expected output?

Task 1: User A
Task 2 (should be clean): null

Actual output?

Task 1: User A
Task 2 (should be clean): User A 😱

Why? Because task1 set the ThreadLocal value, but since the thread was reused from the pool and we didn't call remove(), task2 saw the leftover value from task1.

✅ The Right Way: Always Call `remove()`

Use try-finally to guarantee cleanup:

Runnable safeTask = () -> {
    try {
        threadLocal.set("User B");
        System.out.println("Safe Task: " + threadLocal.get());
    } finally {
        threadLocal.remove(); // Cleanup is critical!
    }
};

Or better yet, abstract it:

public static void withThreadLocal(String value, Runnable action) {
    threadLocal.set(value);
    try {
        action.run();
    } finally {
        threadLocal.remove();
    }
}

Usage:

executor.execute(() ->
    withThreadLocal("User C", () -> {
        System.out.println("Inside safe wrapper: " + threadLocal.get());
    })
);

🧠 Why ThreadLocal Is Tricky in Thread Pools

Internally, each Java Thread has a reference to a ThreadLocalMap. If the thread lives forever (as in a thread pool), so does the map — unless you clean it up.

Even if the ThreadLocal variable itself is GC’d, the thread-local value might still be reachable via the thread’s internal map (depending on GC timing). So just relying on "it'll clean itself up" is dangerous.

🚨How Incorrect `equals()` and `hashCode()` Implementations Cause Memory Leaks in Java

Thellu — Sun, 22 Jun 2025 13:12:02 +0000

When we talk about memory leaks in Java, many developers immediately think of listeners not being removed or caches growing indefinitely. But there's a more subtle and surprisingly common culprit: incorrect implementations of equals() and hashCode().

This post walks through how these two methods — when implemented poorly — can quietly wreak havoc on your application's memory.

The Basics: `equals()` and `hashCode()`

In Java, equals() and hashCode() are used to determine object equality and how objects are stored in hash-based collections like HashMap or HashSet.

A correct contract is:

If two objects are equal (a.equals(b) == true), they must return the same hashCode().
If two objects are not equal, it is not mandatory to return different hash codes — but doing so improves performance.

🔥 What Happens If You Break the Contract?

Let’s look at a real-world-style scenario:

import java.util.HashSet;
import java.util.Set;

public class User {
    private String username;

    public User(String username) {
        this.username = username;
    }

    // Oops! No equals() or hashCode() override!

    public static void main(String[] args) {
        Set<User> users = new HashSet<>();

        for (int i = 0; i < 1000000; i++) {
            users.add(new User("john_doe"));
        }

        System.out.println(users.size()); // Expecting 1? Nope.
    }
}

Expected size? 1

Actual size? 1,000,000

Why? Because each User("john_doe") is a new object with the default hashCode() and equals() — meaning Java thinks they are all different.

💣 Where Memory Leaks Come In

Collections like HashMap and HashSet rely on these two methods for deduplication and key management. If you don’t override them properly, you can:

Create duplicate keys in maps
Grow collections indefinitely
Make it impossible to remove objects (since .remove(obj) depends on equals() working)

And if these collections live for the lifetime of your application — congratulations, you now have a memory leak.

A Real Example: Caching Gone Wrong

Don't think you'll never write stupid code like this, see this example:

Map<User, CachedResult> cache = new HashMap<>();

public CachedResult getResult(User user) {
    return cache.computeIfAbsent(user, this::expensiveOperation);
}

If User doesn't correctly implement equals() and hashCode(), this cache will grow indefinitely, because Java can never recognize that the same user was already cached.

How to Fix It

Always override both equals() and hashCode() together.

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    User user = (User) o;
    return Objects.equals(username, user.username);
}

@Override
public int hashCode() {
    return Objects.hash(username);
}

Or better yet, use Lombok:

@EqualsAndHashCode
public class User {
    private String username;
}

Pro Tip: Watch Out in Unit Tests

Unit tests might not catch this kind of issue if you're only checking content — not behavior in collections. Be sure to test scenarios involving Map, Set, or deduplication logic.

Conclusion

It’s easy to forget the equals()/hashCode() contract until it’s too late. But when misused, they can cause memory leaks that are hard to track down.

So next time you're working with custom objects used as keys in maps or elements in sets — stop and ask: Do I really implement equals() and hashCode() correctly?

DEV Community: Thellu

# Stop Letting Jackson Accept Garbage: Strict JSON Parsing in Spring Boot

What “strict” means (pick your rules)

Step 1) Turn off “accept anything” defaults

Why this matters

Step 2) Define “strict numbers” (the part Jackson won’t solve alone)

Example: strict integer deserializer

Step 3) Money fields: choose one representation and enforce it

Option A: represent money as string (recommended for many APIs)

Option B: represent money as integer minor units

Step 4) Make error responses consistent (so clients can handle them)

Step 5) Lock it with tests

Practical tips (what I wish I knew earlier)

Wrap-up

A Boring Error Format Is a Feature: Building a Consistent Error Envelope in Spring Boot

The error envelope (contract)

Step 1) Define the response model

Step 2) Add a traceId (simple and production-friendly)

Step 3) Create a single place for all exception mapping

Step 4) Example controller to see it in action

Step 5) Tests: lock the contract with MockMvc

Practical tips (the stuff that saves you later)

Wrap-up

`getReferenceById()` Isn’t “No-DB”: What It Really Does in JPA (and When to Use It)

What getReferenceById() actually returns

When it doesn’t query the database

When it will query the database

1) Accessing any non-id field

2) Serializing entity proxies (e.g., returning entities from controllers)

The “surprise exception” people don’t expect

Entity not found… but only later

getReferenceById() vs findById() (practical difference)

findById(id)

getReferenceById(id)

Safe patterns you can copy

✅ Pattern A: “FK-only write path”

✅ Pattern B: “Validate first, then reference”

✅ Pattern C: map to DTOs (avoid proxy serialization traps)

Common foot-guns (learn once, avoid forever)

❌ 1) Calling getReferenceById() and then logging fields

❌ 2) Using Lombok @Data on entities with lazy relations

❌ 3) Using reference outside a transaction and accidentally initializing it

How to prove what’s happening (simple debugging trick)

Rule of thumb

Why `@Transactional` “Doesn’t Work” in Spring: 7 Proxy Gotchas (and Fixes)

0) Quick mental model: where transactions actually start

1) Self-invocation: calling your own method bypasses the proxy

2) Method visibility: non-public methods often won’t be transactional

3) final classes/methods: proxies can’t override them

4) Checked exceptions don’t rollback by default

5) Catching exceptions (and swallowing them) commits the transaction

6) @PostConstruct / constructor calls: proxy isn’t ready yet

7) Async / new threads: transactions are thread-bound

A quick debugging checklist

Recommended rule of thumb

The *Real* Initialization Order of Java Classes (And a Subtle Pitfall)

The Real Initialization Order of Java Classes (And a Subtle Pitfall)

A Surprising Example

What Actually Happens During Initialization

Why This Is Dangerous

Safe Practices for Constructors

1. Avoid calling overridable methods in constructors

2. Base class constructors should only use base-class state

3. Initialize all fields before using them

4. Final methods in base classes are safe

How I Reduced My Oracle SQL Query Time from 110s to 1s

Why Was It So Slow?

1. Huge amount of data

2. Recursive join

⚡ Optimization Step 1 --- Indexing the Join Key

⚡ Optimization Step 2 --- Removing to_date in the WHERE Clause (With Caution)

✅ Final Result

Understanding MySQL Backup Consistency: A Practical Example

Objective

Example Code

Step-by-Step Explanation

Q1 — Set the Isolation Level

Q2 — Start a Consistent Transaction

Q3 — Create a Savepoint

Q4 — Export Table Definition

What `getReferenceById()` actually returns

`getReferenceById()` vs `findById()` (practical difference)

`findById(id)`

`getReferenceById(id)`

❌ 1) Calling `getReferenceById()` and then logging fields

❌ 2) Using Lombok `@Data` on entities with lazy relations

3) `final` classes/methods: proxies can’t override them

6) `@PostConstruct` / constructor calls: proxy isn’t ready yet

The Real Initialization Order of Java Classes (And a Subtle Pitfall)

⚡ Optimization Step 2 --- Removing `to_date` in the WHERE Clause (With Caution)

Comment out `sayHi(char)`

Comment out `sayHi(int)`

Comment out `sayHi(long)`

Comment out `sayHi(Character)`

Comment out `sayHi(Serializable)`

Comment out `sayHi(Object)`

✅ The Right Way: Always Call `remove()`

The Basics: `equals()` and `hashCode()`