Spring Boot Terminology — Interview Reference

Why this matters in interviews

Senior Java interviews consistently probe Spring internals: proxy mechanics, transaction propagation, auto-configuration bootstrapping, and security filter chains. Interviewers expect you to explain not just what an annotation does but why the underlying mechanism works that way — and where it silently breaks. Mastering this vocabulary lets you reason through novel scenarios instead of reciting memorized answers.

Concept

IoC & Dependency Injection

---

Bean Lifecycle & Scopes

---

AOP (Aspect-Oriented Programming)

---

Spring MVC

---

Transactions

---

Spring Boot Specifics

---

Spring Security

---

Key rules / gotchas

• Constructor injection prevents circular dependencies at startup: Spring cannot build the proxy chain if A→B→A all use constructor injection. The error surfaces immediately, which is the correct behavior — fix the design rather than masking it with setter injection.
• @Transactional on private methods is silently ignored: Spring's proxy can only intercept public (or at minimum protected for CGLIB) methods. A private @Transactional method compiles and runs — just without a transaction.
• @Configuration vs @Component CGLIB behavior changes inter-bean calls: Two @Bean methods calling each other inside a @Component-annotated class create two separate bean instances, potentially wiring two different DataSource connections to one EntityManagerFactory.
• Checked exceptions do NOT roll back by default: @Transactional rolls back on RuntimeException and Error only. A service throwing IOException will commit. Always set rollbackFor explicitly for checked exceptions.
• Prototype beans injected into singletons are created only once: A singleton bean captures its prototype dependency at injection time — it holds the same prototype instance for its lifetime. Use ApplicationContext.getBean() or @Lookup to get a fresh prototype each time.
• Profiles and auto-configuration interact: A @ConditionalOnProperty check is evaluated before profile-specific beans are loaded. Ensure your property is set in the correct profile file, not just the active profile bean.
• Filter vs Interceptor order matters for security: Filters run before the servlet context — including DispatcherServlet. Place security-critical logic in a Filter (or SecurityFilterChain) so it cannot be bypassed by Spring routing.
• REQUIRES_NEW suspends, not cancels, the outer transaction: The outer transaction is paused and resumes when the inner one completes. Both transactions are independent — a rollback in the inner does not roll back the outer, and vice versa.
• proxyTargetClass=true breaks injection by interface: When CGLIB is forced, injecting a bean by its interface may fail if the concrete class is final or if Spring cannot subclass it. Ensure target classes are non-final and have a no-arg constructor (or use Objenesis).
• ThreadLocal SecurityContext leaks in async code: SecurityContextHolder is ThreadLocal by default. In @Async or reactive streams, the context is not propagated automatically — use SecurityContextHolder.setStrategyName(MODE_INHERITABLETHREADLOCAL) or reactive ReactiveSecurityContextHolder.

Code example

import java.util.function.Supplier;

/**
 * Runnable plain-Java simulation of four Spring concepts:
 *  1. Constructor DI (vs field injection)
 *  2. AOP proxy self-invocation pitfall
 *  3. Transaction propagation (REQUIRED vs REQUIRES_NEW)
 *  4. Bean lifecycle phases (@PostConstruct → use → @PreDestroy)
 */
public class JavaLabRunner {

    // ─── 1. CONSTRUCTOR DI ───────────────────────────────────────────────────

    interface PaymentGateway {
        String charge(double amount);
    }

    static class StripeGateway implements PaymentGateway {
        @Override
        public String charge(double amount) {
            return "Stripe charged $" + amount;
        }
    }

    /**
     * Good: constructor injection — dependency is explicit, final, and
     * testable without a Spring context.
     */
    static class OrderService {
        private final PaymentGateway paymentGateway;   // final — immutable

        // Spring would call this constructor automatically (single constructor rule)
        OrderService(PaymentGateway paymentGateway) {
            this.paymentGateway = paymentGateway;
        }

        String placeOrder(double amount) {
            return paymentGateway.charge(amount);
        }
    }

    // ─── 2. AOP SELF-INVOCATION PITFALL ─────────────────────────────────────

    /**
     * In Spring, @Transactional and @Cacheable work through a proxy wrapping
     * the bean. When a method calls *this*.otherMethod(), it bypasses the proxy
     * — no transaction / cache is applied.
     *
     * This simulation shows the difference between proxy-mediated calls and
     * direct self-calls.
     */
    interface InvoiceService {
        void processInvoice(int id);
        void sendNotification(int id);   // should be "transactional"
    }

    static class InvoiceServiceImpl implements InvoiceService {
        private boolean inTransaction = false;

        @Override
        public void processInvoice(int id) {
            System.out.println("[processInvoice] transaction active? " + inTransaction);
            // PITFALL: direct `this` call — bypasses any proxy wrapping
            this.sendNotification(id);
            System.out.println("[sendNotification via self-invocation] transaction active? " + inTransaction);
        }

        @Override
        public void sendNotification(int id) {
            // In real Spring this would be @Transactional(REQUIRES_NEW)
            // but self-invocation means the proxy is never entered
            System.out.println("  Sending notification for invoice " + id + " (no new transaction started!)");
        }
    }

    /**
     * Proxy wrapper simulating what Spring's CGLIB proxy does when you call
     * through the bean reference (not `this`).
     */
    static class InvoiceServiceProxy implements InvoiceService {
        private final InvoiceServiceImpl target;

        InvoiceServiceProxy(InvoiceServiceImpl target) {
            this.target = target;
        }

        @Override
        public void processInvoice(int id) {
            System.out.println("[PROXY] entering outer transaction (REQUIRED)");
            target.inTransaction = true;
            target.processInvoice(id);
            target.inTransaction = false;
            System.out.println("[PROXY] outer transaction committed");
        }

        @Override
        public void sendNotification(int id) {
            // Called via proxy reference — a NEW transaction would be started here
            System.out.println("[PROXY] suspending outer tx, starting REQUIRES_NEW transaction");
            target.inTransaction = false;   // simulate suspended outer
            target.sendNotification(id);
            target.inTransaction = true;    // resume outer
            System.out.println("[PROXY] REQUIRES_NEW committed, outer tx resumed");
        }
    }

    // ─── 3. TRANSACTION PROPAGATION SIMULATION ──────────────────────────────

    static class TransactionSimulator {
        private String currentTx = null;

        /**
         * REQUIRED: join existing or create new.
         */
        void required(String txName, Runnable work) {
            boolean isNew = (currentTx == null);
            if (isNew) {
                currentTx = txName;
                System.out.println("  [REQUIRED] started new transaction: " + currentTx);
            } else {
                System.out.println("  [REQUIRED] joined existing transaction: " + currentTx);
            }
            work.run();
            if (isNew) {
                System.out.println("  [REQUIRED] committed transaction: " + currentTx);
                currentTx = null;
            }
        }

        /**
         * REQUIRES_NEW: suspend outer, start fresh, resume outer.
         */
        void requiresNew(String txName, Runnable work) {
            String suspended = currentTx;
            if (suspended != null) {
                System.out.println("  [REQUIRES_NEW] suspending '" + suspended + "'");
            }
            currentTx = txName;
            System.out.println("  [REQUIRES_NEW] started new transaction: " + currentTx);
            work.run();
            System.out.println("  [REQUIRES_NEW] committed independent transaction: " + currentTx);
            currentTx = suspended;
            if (suspended != null) {
                System.out.println("  [REQUIRES_NEW] resumed '" + suspended + "'");
            }
        }
    }

    // ─── 4. BEAN LIFECYCLE PHASES ────────────────────────────────────────────

    static class ReportingBean {
        private String dataSource;

        // Simulates @Autowired constructor injection
        ReportingBean(String dataSource) {
            this.dataSource = dataSource;
            System.out.println("[Lifecycle] 1. Constructor called — dataSource injected");
        }

        // Simulates @PostConstruct
        void postConstruct() {
            System.out.println("[Lifecycle] 2. @PostConstruct — validating dataSource: " + dataSource);
            if (dataSource == null || dataSource.isBlank()) {
                throw new IllegalStateException("dataSource must be configured");
            }
        }

        String generateReport() {
            System.out.println("[Lifecycle] 3. Bean in use — generating report from: " + dataSource);
            return "REPORT[" + dataSource + "]";
        }

        // Simulates @PreDestroy
        void preDestroy() {
            System.out.println("[Lifecycle] 4. @PreDestroy — releasing resources for: " + dataSource);
            dataSource = null;
        }
    }

    // ─── MAIN ────────────────────────────────────────────────────────────────

    public static void main(String[] args) {
        System.out.println("═══ 1. CONSTRUCTOR DI ═══");
        PaymentGateway gateway = new StripeGateway();
        OrderService orderService = new OrderService(gateway);   // no Spring needed for unit tests
        System.out.println(orderService.placeOrder(99.99));

        System.out.println("\n═══ 2. AOP SELF-INVOCATION PITFALL ═══");
        InvoiceServiceImpl rawImpl = new InvoiceServiceImpl();
        InvoiceService proxy = new InvoiceServiceProxy(rawImpl);

        System.out.println("-- Called through proxy (correct behavior) --");
        proxy.processInvoice(42);   // outer via proxy → self-call bypasses proxy for sendNotification

        System.out.println("\n-- Called through proxy reference for sendNotification (what you SHOULD do) --");
        proxy.sendNotification(42);  // new transaction starts correctly

        System.out.println("\n═══ 3. TRANSACTION PROPAGATION ═══");
        TransactionSimulator tx = new TransactionSimulator();

        System.out.println("Scenario A: outer REQUIRED → inner REQUIRED (joins)");
        tx.required("TX-outer", () ->
            tx.required("TX-inner", () ->
                System.out.println("  [work] running inside shared transaction")
            )
        );

        System.out.println("\nScenario B: outer REQUIRED → inner REQUIRES_NEW (independent)");
        tx.required("TX-outer", () ->
            tx.requiresNew("TX-audit", () ->
                System.out.println("  [audit] writing audit log in independent transaction")
            )
        );

        System.out.println("\n═══ 4. BEAN LIFECYCLE ═══");
        ReportingBean bean = new ReportingBean("jdbc:postgresql://localhost/mydb");
        bean.postConstruct();
        System.out.println(bean.generateReport());
        bean.preDestroy();
    }
}

Interview questions you should be able to answer

• Q: Why is constructor injection preferred over field injection in Spring?

  Constructor injection makes dependencies explicit (visible in the constructor signature), allows fields to be final (ensuring immutability and thread safety), and enables the class to be instantiated and unit-tested without a Spring context. Field injection hides dependencies, prevents final, and requires reflection or a Spring container to inject, making isolated unit tests painful. Additionally, missing required dependencies fail fast at application startup with constructor injection rather than at runtime.

• Q: You annotate a private method with @Transactional. The method is called from a public method in the same class. Why is no transaction started?

  Spring's @Transactional works through a proxy — either a JDK dynamic proxy or a CGLIB subclass. The proxy intercepts calls to public methods made through the bean reference. When a method calls this.privateMethod(), it bypasses the proxy entirely and invokes the concrete implementation directly. No proxy interception occurs, so no transaction is started. The fix is to either make the method public and move the call through a separate Spring-managed bean reference, or to use AspectJ compile-time or load-time weaving which is not proxy-based.

• Q: What is the difference between REQUIRES_NEW and REQUIRED transaction propagation?

  REQUIRED (the default) joins the current transaction if one exists; if not, it starts a new one. Both the outer and inner operations commit or roll back together. REQUIRES_NEW always starts a brand-new, independent transaction, suspending the outer transaction if one is active. The inner transaction commits or rolls back independently — a rollback in the inner does not affect the outer and vice versa. Use REQUIRES_NEW for operations like audit logging that must persist even if the main business transaction rolls back.

• Q: How does Spring Boot auto-configuration work?

  At startup, Spring Boot reads META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (Boot 2.7+; previously spring.factories). This file lists @Configuration classes from all starters on the classpath. Spring Boot imports each one, but each class is guarded by @Conditional annotations — @ConditionalOnClass checks for a required class, @ConditionalOnMissingBean skips the auto-configured bean if you already defined your own, and @ConditionalOnProperty checks a configuration flag. This allows starters to register sensible defaults that your own beans or properties can override without touching starter code.

• Q: Why does @Configuration require CGLIB proxying, and what breaks if you use @Component instead?

  A @Configuration class is proxied by CGLIB so that calls between @Bean methods return the same singleton bean rather than a new object each time. For example, if entityManagerFactory() calls dataSource() and transactionManager() also calls dataSource(), both get the same DataSource instance because CGLIB intercepts the call and returns the existing bean from the context. If you use @Component (lite mode, no CGLIB), dataSource() is a plain Java method call — each invocation creates a new DataSource instance, resulting in multiple connections, uncommitted transactions, and potential data corruption.

• Q: What is the difference between READ_COMMITTED and REPEATABLE_READ isolation levels, and when would you choose each?

  READ_COMMITTED prevents dirty reads (you only see committed data) but allows non-repeatable reads — if you SELECT the same row twice in one transaction and another transaction commits a change between those reads, you see different values. REPEATABLE_READ additionally prevents non-repeatable reads: once a row is read in a transaction, subsequent reads of that row return the same value even if another transaction commits changes. However, REPEATABLE_READ still allows phantom reads (new rows inserted by other transactions appearing in range queries). Choose READ_COMMITTED for most OLTP workloads where performance matters and stale reads of the same row are acceptable. Choose REPEATABLE_READ (or SERIALIZABLE) when consistency within a single transaction is critical — for example, reading an account balance twice to validate and then deduct an amount.

Further reading

• Spring Framework Reference — Core: IoC Container — https://docs.spring.io/spring-framework/docs/current/reference/html/core.html
• Spring Framework Reference — AOP — https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#aop
• Spring Framework Reference — Data Access / Transactions — https://docs.spring.io/spring-framework/docs/current/reference/html/data-access.html#transaction
• Spring Boot Reference — Auto-configuration — https://docs.spring.io/spring-boot/docs/current/reference/html/using.html#using.auto-configuration
• Spring Security Reference — Architecture — https://docs.spring.io/spring-security/reference/servlet/architecture.html
• Baeldung — Spring @Transactional Propagation and Isolation — https://www.baeldung.com/spring-transactional-propagation-isolation
• Baeldung — Spring AOP Self-invocation — https://www.baeldung.com/spring-aop-self-invocation
• Baeldung — @Configuration vs @Component — https://www.baeldung.com/spring-configuration-vs-component