jpa-patterns
This skill addresses the most common JPA performance bottlenecks: N+1 query problems, lazy loading errors, and transaction misconfigurations. It covers practical solutions like JOIN FETCH and EntityGraph for efficient data fetching, explains when to use LAZY vs EAGER loading, and demonstrates transaction management best practices for Spring applications.
jpa-patterns helps you identify and resolve N+1 query problems using JOIN FETCH, EntityGraph, and batch fetching strategies.
AI-generated summary based on this skill's SKILL.md
Install
decebals/claude-code-java/jpa-patterns · repository language: Shell
git clone https://github.com/decebals/claude-code-java
cp -r claude-code-java/.claude/skills/jpa-patterns ~/.claude/skills/jpa-patternsnpx skillfed install decebals/claude-code-java/jpa-patternsFrequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
How to fix N+1 query problem in JPA?
jpa-patterns addresses N+1 queries by teaching JOIN FETCH and EntityGraph strategies. The core issue: loading a parent entity triggers separate queries for each child. jpa-patterns shows how to use JOIN FETCH in JPQL queries to eagerly load relationships in a single query, or EntityGraph annotations to specify fetch plans declaratively. For Spring Data repositories, use @EntityGraph on custom query methods. Batch fetching via hibernate.default_batch_fetch_size also reduces round trips by loading multiple entities per query.
What causes LazyInitializationException in Spring Boot Hibernate?
jpa-patterns explains that LazyInitializationException occurs when accessing a lazily-loaded relationship outside an active transaction or session. Common scenarios: returning entities from a service method after the transaction closes, or accessing lazy fields in a view layer. Solutions include: wrapping access in @Transactional, using JOIN FETCH to eagerly load needed relationships, converting to DTOs before transaction end, or enabling Open Session In View (though this can mask design issues). Choose based on your architecture.
When should jpa-patterns recommend EAGER vs LAZY fetch strategies?
jpa-patterns teaches that LAZY is the safer default: it loads data only when accessed, reducing memory and query overhead. Use LAZY for relationships you don't always need. Switch to EAGER only when a relationship is almost always accessed together with the parent—but this risks loading unnecessary data. Better practice: keep relationships LAZY and use JOIN FETCH or EntityGraph in specific queries where you know you need them. This gives you explicit control and avoids hidden performance surprises.
How does jpa-patterns handle transaction management and concurrency?
jpa-patterns covers Spring @Transactional configuration, propagation levels, and isolation settings for safe concurrent access. For preventing lost updates, it demonstrates optimistic locking via @Version fields: JPA increments the version on each update, and concurrent modifications fail with OptimisticLockException. Pessimistic locking with LockModeType.PESSIMISTIC_WRITE is also shown for high-contention scenarios. Proper transaction boundaries, cascade types, and dirty-checking behavior are explained to avoid common concurrency pitfalls.
What's the difference between JOIN FETCH and EntityGraph in jpa-patterns?
jpa-patterns contrasts these two eager-loading approaches: JOIN FETCH is a JPQL syntax that explicitly joins and fetches related entities in a single query—simple but couples your query logic to fetch strategy. EntityGraph is a declarative annotation-based approach that specifies fetch plans separately from queries, allowing reuse across multiple query methods. EntityGraph is more flexible for complex entity graphs and repository-based queries, while JOIN FETCH gives finer control in custom JPQL. Choose based on whether you prefer query-level or metadata-level fetch definition.
How can jpa-patterns help optimize queries with pagination and projections?
jpa-patterns demonstrates Spring Data JPA pagination via Pageable parameters and PagingAndSortingRepository, which automatically handles limit/offset. For large result sets, it shows DTO projections: querying only needed columns instead of full entities reduces memory and serialization overhead. Use @Query with constructor expressions or interface-based projections. Bulk operations (updateQuery, deleteInBatch) bypass entity instantiation for mass changes. Combined with proper indexing and fetch strategies, these techniques significantly improve throughput on large datasets.
SKILL.md
rendered from the published skill — quoted content, verbatim
JPA Patterns Skill
Best practices and common pitfalls for JPA/Hibernate in Spring applications.
When to Use
- User mentions "N+1 problem" / "too many queries"
- LazyInitializationException errors
- Questions about fetch strategies (EAGER vs LAZY)
- Transaction management issues
- Entity relationship design
- Query optimization
Quick Reference: Common Problems
| Problem | Symptom | Solution |
|---|---|---|
| N+1 queries | Many SELECT statements | JOIN FETCH, @EntityGraph |
| LazyInitializationException | Error outside transaction | Open Session in View, DTO projection, JOIN FETCH |
| Slow queries | Performance issues | Pagination, projections, indexes |
| Dirty checking overhead | Slow updates | Read-only transactions, DTOs |
| Lost updates | Concurrent modifications | Optimistic locking (@Version) |
N+1 Problem
> The #1 JPA performance killer
The Problem
```java // ❌ BAD: N+1
(truncated - see the full file via the links below)
Read as markdown · JSON record · Browse the source repository
File tree — 2 files
.claude/skills/jpa-patterns/README.md
.claude/skills/jpa-patterns/SKILL.md