```mermaid theme={null}
graph TD
App[Spring Boot App] --> Repo[Spring Data Repository]
Repo --> EM[JPA EntityManager]
EM --> Hibernate[Hibernate Core]
Hibernate --> JDBC[JDBC Driver]
JDBC --> DB[(Database)]
```
## 12. Deep Dive: Transaction Management
Handling transactions correctly is what separates seniors from juniors.
### Propagation Levels (`@Transactional(propagation = ...)`)
| Level | Description | Use Case |
| :------------------- | :------------------------------------------------------------------- | :----------------------------------------------------------------- |
| `REQUIRED` (Default) | Join existing transaction. If none, create new. | Most business logic. |
| `REQUIRES_NEW` | **Suspend** current transaction. Create a brand new independent one. | Audit logging (save log even if main logic fails). |
| `MANDATORY` | Must be called inside a transaction. Else throw Exception. | Helper methods that shouldn't run standalone. |
| `SUPPORTS` | Run in transaction if exists. Else run non-transactional. | Read-only operations. |
| `NOT_SUPPORTED` | Suspend current transaction. Run non-transactional. | Sending emails/long processes (don't hold DB lock). |
| `NESTED` | Create a **Savepoint** within the existing transaction. | Complex rollbacks (try sub-task, if fail, rollback only sub-task). |
### Isolation Levels (`@Transactional(isolation = ...)`)
Defines "how much" one transaction sees of another.
1. **READ\_UNCOMMITTED**: Dirty Reads allowed. (Dangerous).
2. **READ\_COMMITTED**: PostgreSQL Default. No Dirty Reads.
3. **REPEATABLE\_READ**: No Non-Repeatable Reads. (MySQL Default).
4. **SERIALIZABLE**: Full locking. Slowest but safest.
### Rollback Rules
By default, Spring **ONLY** rolls back on `RuntimeException` (Unchecked).
It does **NOT** rollback on `CheckedException` (e.g., `IOException`).
This is one of the most dangerous default behaviors in Spring. Your method throws an `IOException`, the transaction commits the partial state, and you now have corrupted data in production. Nothing in the logs tells you the transaction committed -- you only find out when a customer reports a wrong balance.
**Fix:**
```java theme={null}
@Transactional(rollbackFor = Exception.class) // Rollback for ALL exceptions, not just unchecked
public void dangerousMethod() throws IOException { ... }
```
**Production tip:** Many teams adopt a project-wide convention of always using `rollbackFor = Exception.class` on every `@Transactional` annotation. You can enforce this at the team level by creating a custom `@BusinessTransaction` meta-annotation:
```java theme={null}
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Transactional(rollbackFor = Exception.class)
public @interface BusinessTransaction {}
// Usage: cleaner and team-consistent
@BusinessTransaction
public void transferFunds(Long from, Long to, BigDecimal amount) throws InsufficientFundsException { ... }
```
## 13. High-Performance Caching
Caching is **the easiest way** to improve performance. Spring provides an abstraction over multiple caching providers.
### Enable Caching
```java theme={null}
@SpringBootApplication
@EnableCaching
public class DemoApplication {}
```
### Basic Usage
```java theme={null}
@Service
public class ProductService {
@Cacheable("products") // Cache the result using key = id
public Product getProduct(Long id) {
// Expensive DB call
return productRepository.findById(id).orElseThrow();
}
@CacheEvict(value = "products", key = "#id")
public void deleteProduct(Long id) {
productRepository.deleteById(id);
}
@CachePut(value = "products", key = "#product.id")
public Product updateProduct(Product product) {
return productRepository.save(product);
}
}
```
**Annotations:**
* `@Cacheable`: If key exists in cache, return cached value. Else, execute method and cache the result.
* `@CacheEvict`: Remove from cache.
* `@CachePut`: Always execute method AND update cache.
### Using Redis (Production)
By default, Spring uses `ConcurrentHashMap` (in-memory). This works fine for a single instance, but the moment you scale to multiple pods, each pod has its own independent cache. User A hits Pod 1 (cache miss, loads from DB), then User A hits Pod 2 (another cache miss, loads from DB again). You have zero cache benefit under a load balancer.
For distributed systems, use **Redis** -- a shared, external cache that all pods read from.
**Dependency:**
```xml theme={null}