Top 5 Spring Interview Questions
Browse 5 real-world technical and behavioral interview questions about Spring. Review scenarios, edge cases, and architectural best practices.
A method with REQUIRES_NEW was meant to save an audit row even when the main transaction fails. When does it work, and when does it deadlock?
REQUIRES_NEW suspends the caller's transaction and commits the audit on a second connection, so the row survives a later rollback if the call goes through the Spring proxy. It hangs when the audit touches rows the suspended transaction has locked, or when every thread holds one pooled connection and waits for another.
Startup fails with NoUniqueBeanDefinitionException after someone adds a second implementation. Do you reach for @Primary, @Qualifier or a list of beans, and which fix ages badly?
NoUniqueBeanDefinitionException means one injection point matches two beans by type. Fix it where the decision belongs: a qualifier at the consumer when callers need different beans, a List or Map when all are used, a conditional bean when only one should exist. A primary bean is the quick fix that ages worst.
A singleton service depends on a prototype-scoped bean, and every caller gets the same instance. Why, and how do you get a fresh one per use?
Prototype scope means a new instance per request to the container, and a singleton asks once, at construction. Inject an ObjectProvider and call getObject() each time you need a fresh instance. A scoped proxy also works, but on a prototype it creates a new target on every method call, which is rarely what you meant.
Why does @Transactional sometimes do nothing at all, even though the annotation is right there?
Spring applies @Transactional through a proxy that wraps the bean. Calling the annotated method from another method of the same class goes through `this`, not the proxy, so the advice never runs and no transaction is started. The same silence affects @Cacheable, @Async and @Retryable. It also connects dependency injection to the point an interviewer is testing.
The inner service threw, you caught the exception in the caller, and then the commit failed with UnexpectedRollbackException. Why?
The inner method joined the caller's transaction, so its rollback rule marked the one physical transaction rollback-only. Catching the exception hides it from your code but not from the transaction manager, which then refuses to commit. Use REQUIRES_NEW when the inner work must be able to fail alone.