Data Management — the 34 you got wrong

NOT_SUPPORTED

Take the stem apart clause by clause — the exam builds these definitions from exactly two facts:

What suspension actually does, because knowing the mechanism makes the table stick: AbstractPlatformTransactionManager calls doSuspend(), which unbinds the ConnectionHolder/EntityManagerHolder from TransactionSynchronizationManager and stashes it. The inner method then runs with a clean thread state — any JDBC call it makes gets its own connection in auto-commit — and the resources are rebound afterwards.

The practical trap: a NOT_SUPPORTED method that then uses the same EntityManager will fail, because the EM is unbound. And calling it via this. from inside the transactional method bypasses the proxy, so no suspension happens at all and the code silently runs inside the outer transaction.

NEVER

Only two propagation levels throw at all, and they throw on opposite conditions. Learn them as a pair and both questions collapse into one fact:

Both throw the same exception — IllegalTransactionStateException — which is itself a commonly-asked detail. Read them as assertions rather than behaviours: MANDATORY says "my caller must have opened a transaction"; NEVER says "I must not be inside one". Neither ever creates a transaction.

REQUIRED

REQUIRED is the default for @Transactional and for TransactionDefinition, and it is what you want essentially always: join the caller's transaction so the whole request commits or rolls back as one unit; start one if the caller had none.

The contrast worth owning, because it's the other stock question: REQUIRES_NEW takes a second connection from the pool while the outer transaction still holds the first. Its legitimate use is work that must survive the caller's rollback — audit records, failure logs. Its hazard is that a pool sized for one connection per request can deadlock against itself under load.

unit of work, and auto-commit

This is the raw JDBC that Spring's transaction abstraction hides:

connection.setAutoCommit(false);   // ← the mode you must disable
try {
    // several statements — together, the unit of work
    connection.commit();
} catch (Exception e) {
    connection.rollback();
}

Auto-commit is JDBC's default, and with it on every single statement is its own transaction — so there is nothing to roll back as a group. Spring's transaction managers do exactly this for you: DataSourceTransactionManager.doBegin() calls setAutoCommit(false), binds the connection to the thread, and restores the flag on completion.

Note the term the other distractors used: transaction demarcation is the act of marking where a transaction begins and ends — which is what @Transactional (declarative) and TransactionTemplate (programmatic) do. That's vocabulary worth having, since questions use it as a stem.

The transaction commits, and the exception still propagates

The default rule, and the four attributes that bend it:

Two things people get wrong about this. First, noRollbackFor does not swallow the exception — it still propagates to the caller; it only changes the commit/rollback decision. Second, every rollback attribute contains the word For: there is no bare rollback attribute, which is a stock "which of these is not an attribute" trap.

The legitimate use case: a business-rule violation that should still persist something written earlier in the same transaction — an audit row, an attempt counter. Use it sparingly.

isolation and propagation — writeOnly, readWrite and nestedTransaction don't exist

The complete attribute list, which is short enough to hold whole:

Note what isn't there: no nesting attribute (that's propagation = Propagation.NESTED), no retry, no writeOnly. And @Transactional does not support SpEL — every value is a fixed constant, enum or class literal.

Global transactions — managed by JTA

Two kinds of transaction, and the manager each one needs:

Global transactions use two-phase commit (2PC): a prepare phase where every resource confirms it can commit, then a commit phase where they all do — or all roll back if any resource refused. That's what makes "write to the DB and post to the queue atomically" possible, and why it needs XA-capable drivers and an external transaction coordinator.

The exam point behind the vocabulary: Spring's PlatformTransactionManager abstraction means your application code doesn't change when you move from local to global — you swap the manager bean, not the @Transactional annotations. And don't confuse global (multi-resource) with nested (a savepoint inside one transaction).

DataSourceTransactionManager

The four implementations, and when Boot picks each:

The pitfall worth knowing: JpaTransactionManager also manages the underlying JDBC connection, so one manager covers both your JPA code and plain JdbcTemplate code sharing the same DataSource. Declaring both a JpaTransactionManager and a DataSourceTransactionManager on the same DataSource is a classic misconfiguration — the JDBC one bypasses the EntityManager lifecycle and flushes happen at the wrong time, or not at all.

And if several managers do exist in the context, @Transactional must name one: @Transactional("jpaTxManager").

READ_UNCOMMITTED and READ_COMMITTED

Read the staircase downwards for "can occur", upwards for "prevented":

REPEATABLE_READ is the level whose name is the guarantee — re-reading a row inside one transaction returns the same value. Anything weaker allows the row to change under you.

REPEATABLE_READ and SERIALIZABLE

Treat "which prevent" and "which allow" as the same question. The four levels split two-and-two on non-repeatable reads, so whichever way it's asked the answer is a pair:

Notice the counts — 1, 2, 3. Dirty reads are possible at exactly one level, non-repeatable at two, phantoms at three. If your answer doesn't have that many options ticked, you've made a mistake.

READ_COMMITTED

Three constraints, and each one eliminates:

READ_COMMITTED is worth knowing well for a second reason: it is the default in PostgreSQL, Oracle and SQL Server, so it's what Isolation.DEFAULT resolves to in most real applications. MySQL InnoDB is the outlier at REPEATABLE_READ.

queryForObject(sql, RowMapper<T>, args…)

The single-row family, and what each one hands back:

All the queryFor…Object/Map variants enforce cardinality at the Spring layer: zero rows throws EmptyResultDataAccessException, more than one throws IncorrectResultSizeDataAccessException. That's the most-asked fact about queryForObject. If "not found" is a normal outcome for you, use query(...).stream().findFirst() instead of catching.

On mappers: BeanPropertyRowMapper matches columns to JavaBean properties (case-insensitive, underscores auto-mapped) and silently leaves fields at defaults when a column is missing or misspelled. DataClassRowMapper (Spring 5.3+) does constructor binding and works with records.

Resource management, SQL execution, boilerplate — and it translates exceptions rather than rethrowing them

The four responsibilities, which is what "what does JdbcTemplate do" questions enumerate:

Why translation matters, and why it's always in these questions: the JDBC SQLException is checked, and its meaning depends on vendor-specific error codes. Spring maps those codes onto a consistent, unchecked hierarchy — so a unique-constraint violation is DuplicateKeyException whether you're on Postgres or Oracle, and the same hierarchy also covers JPA and Hibernate. That's what lets you swap persistence technology without touching a catch block.

Note that JdbcTemplate does not manage transactions — that's the transaction manager's job — and it is thread-safe once configured, which is why you inject one shared instance.

It relies on inheritance, which couples subclass to superclass

The classic GoF pattern fixes an algorithm's skeleton in a base class and delegates the variable steps to abstract methods a subclass overrides. The cost is a compile-time relationship you can't change: Java's single inheritance means the subclass can't also extend anything else, and swapping the skeleton means a new hierarchy.

The reason this is a Spring question at all: JdbcTemplate deliberately sidesteps that cost. Instead of asking you to subclass it, it takes callback objects — RowMapper, ResultSetExtractor, PreparedStatementCreator — so the variable part arrives by composition:

Internally JdbcTemplate does use the pattern — execute(StatementCallback<T>) holds the fixed skeleton (acquire connection → create statement → execute → translate exceptions → release) — but it exposes only the callback surface. That's the design insight the question is fishing for.

A primary-key or unique-constraint violation on INSERT or UPDATE

The subclasses that actually appear in questions, each mapped to its cause:

The chain for this one: DuplicateKeyException → DataIntegrityViolationException → NonTransientDataAccessException → DataAccessException → RuntimeException. That transient / non-transient split is itself a useful fact: a transient failure (deadlock, lock timeout, connection blip) may succeed if you retry; a non-transient one (duplicate key, bad SQL) never will.

And the ordering rule the code in that question demonstrated — catch specific before general. Since every one of these is unchecked, nothing forces you to catch anything, which is deliberate: most data-access failures aren't recoverable at the call site.

No — extending the interface is what makes it discoverable

@EnableJpaRepositories (or Boot's auto-configuration) scans for interfaces extending Repository — including CrudRepository, PagingAndSortingRepository and JpaRepository — builds a proxy implementation for each at runtime, and registers it as a bean. @Repository adds nothing.

Worth separating the annotation's two jobs, because that's what makes the question confusing: @Repository is a @Component stereotype (registers the bean), and it triggers PersistenceExceptionTranslationPostProcessor to convert provider-specific exceptions into DataAccessException. Spring Data proxies already do both, which is why the annotation is redundant there.

findByAgeIsDifferentNull — there's no such keyword

The keyword vocabulary is finite, and everything outside it is invented:

Structure to check against: subject (find, read, get, query, count, exists, delete, remove) + By + predicate. By is mandatory — deleteAgeLessThan is invalid, deleteByAgeLessThan is fine. And property names must match entity fields, so a bad name fails at application startup, not at call time.

@EnableJpaRepositories scans sub-packages too — and CRUD methods inherit SimpleJpaRepository's transactions

Four facts, three of which were the correct options:

The transactional detail is worth knowing properly, because it explains real behaviour: SimpleJpaRepository is annotated @Transactional(readOnly = true) at class level, and its write methods (save, delete, deleteAll) override that with a plain @Transactional. So every repository call is transactional even if you never annotate anything — and a save() called with no surrounding transaction commits on its own. Wrap several calls in your own @Transactional service method to make them atomic.

JPQL by default · method-level only · supports SpEL

Everything the annotation does:

@Query("select u from User u where u.email = ?1")                       // JPQL
User findByEmail(String email);

@Query(value = "select * from users where email = ?1", nativeQuery = true)  // SQL
User findByEmailNative(String email);

@Modifying
@Query("update User u set u.active = false where u.lastLogin < ?1")
int deactivateStale(LocalDate cutoff);

The reason JPQL is the default: it's portable across JPA providers and databases, since it is written against your entity model. Native SQL buys you database-specific features at the cost of that portability, which is why it has to be requested explicitly.

Nothing — @Param isn't needed with indexed parameters

Two independent facts made "none of the above" correct:

// indexed — no @Param
@Query("select p from Person p where p.emailAddress = ?1")
Person findByEmailAddress(String emailAddress);

// named — @Param required
@Query("select p from Person p where p.emailAddress = :email")
Person findByEmailAddress(@Param("email") String emailAddress);

Prefer named parameters in anything non-trivial — they survive reordering and read far better — and never mix the two styles in one query. (Since Java 8, if you compile with -parameters, @Param can sometimes be inferred; don't rely on it in an exam answer.)

The wider lesson: when "None of the above" is an option, the exam is usually testing whether you'll invent a rule that doesn't exist. Check each proposed fault against a real rule before accepting it.

DataSource · EntityManagerFactory · JpaTransactionManager · entities · the JARs

Manual JPA configuration is four beans plus a classpath — and knowing the shape explains what Boot is doing for you:

There is no "enable JPA" flag. Spring wires a JPA provider into the container by declaring beans; Boot's HibernateJpaAutoConfiguration then creates all four automatically when spring-boot-starter-data-jpa is on the classpath. That's why the property option was invented — Boot triggers on classpath presence, not on a switch.

One naming trap: LocalEntityManagerFactoryBean (without Container) skips Spring's packages-to-scan support and requires a persistence.xml — almost never what you want.

spring.datasource.driver-class-name — deduced from the URL

DataSourceBuilder reads the JDBC URL prefix and maps it to a driver class:

spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.datasource.username=app
spring.datasource.password=secret
# driver-class-name: not needed

Set it explicitly only when auto-detection fails or you're deliberately overriding. And remember the neighbouring fact: with no spring.datasource.* at all and H2/HSQLDB/Derby on the classpath, Boot stands up an embedded database automatically — which is what @DataJpaTest exploits.

Alters the schema to match your entities at startup — additively, never dropping

All five values, and where each belongs:

Why update is unsafe in production — a favourite follow-up: it adds columns and tables but never removes or narrows anything, so schema drift accumulates silently and a renamed field leaves the old column behind, still NOT NULL. Real schema management is Flyway or Liquibase, with ddl-auto=validate as a safety net.

Boot's own defaults: create-drop for an embedded database and none otherwise. And note the neighbouring property from the same config block — spring.jpa.show-sql=true logs statements; it has nothing to do with DDL.

GenerationType.AUTO — the provider then chooses

Bare @GeneratedValue means @GeneratedValue(strategy = GenerationType.AUTO). In Hibernate 5, AUTO maps to SequenceStyleGenerator, which then picks per dialect:

The practical follow-up: IDENTITY forces Hibernate to execute the INSERT immediately on persist() to learn the generated key, which disables insert batching. SEQUENCE lets it pre-fetch ids and batch — which is why explicit SEQUENCE is recommended where the database supports it.