Performance: Large IN, Dirty Checking, OSIV

A large IN clause with thousands of IDs causes huge SQL, plan cache pollution, parameter limits, and poor optimizer decisions – fix by chunking into batches of 500, using a temp table, or redesigning to a server-side filter.

@Transactional(readOnly=true) skips dirty checking (no snapshots, no field comparisons) and hints the JDBC connection as read-only; OSIV keeps the session open through JSON serialization, masking lazy-load problems while holding connections too long.

Never dump 10,000 literals into one IN clause: chunk into bounded batches, pass as a database array and join, or keep the filter server-side as a subquery.

readOnly=true skips dirty checking and enables replica reads; OSIV keeps the session open too long and hides N+1 queries, so disable it.

OSIV keeps the persistence context open through view rendering so lazy loads work during serialization, hiding LazyInitializationException, but it leaks database access into the view and causes N+1 queries.

Default UPDATE sets all columns for statement reuse; `@DynamicUpdate` writes only changed columns; `merge()` copies the entire detached state, so null fields can blank existing data.