Spring application development involves multiple frameworks from the Spring ecosystem: Spring Boot for the configuration and packaging, Spring Framework for the core features and dependency injection, Spring MVC for the web components, Spring Data for the persistence, Spring Security, Spring Test, and many others.
As a consequence, evaluating a developer's knowledge of Spring can be tricky, and there are many possible questions to ask. If you search "Spring interview questions", you will find dozens of lists with hundreds of questions, ranging from the simplest to the most complex.
Narrowing it down to a single question is very difficult, biased and risky. But I have one such question in mind.
In this article, I will share that question along with my answer and explain why it is so important.
If I had to choose a single question to ask in a Spring interview, I would pick this one:
spring.jpa.open-in-view parameter?Admittedly, this is a highly opinionated choice, but I think that this question is useful to assess a developer's understanding of several core concepts of Spring application development including web design, persistence, transaction and performance.
This question is interesting because it is open-ended and admits several levels of response. Developers can answer at a high level about the concept, discuss trade-offs, provide concrete examples, or propose alternatives.
It is not suitable for beginner-level interviews, but should be insightful for intermediate to advanced-level ones.
The goal is not to trap the developer but to give them an opportunity to shine. If they do not know this parameter, ask them what they can tell about the Open Session In View pattern in a Spring Boot application. Encourage developers to explain their reasoning and, if they are short on ideas, guide them with hints or narrow the question down to specific aspects.
This parameter is relevant for web Spring applications using JPA. It is used to determine whether the Open Session In View (OSIV) pattern is enabled or not in a Spring Boot application.
Its default value is true, accompanied by a warning, which means that OSIV is enabled by default
but a warning is logged during application startup to encourage developers to make a choice:
15:09:36.031 WARN JpaBaseConfiguration$JpaWebConfiguration : spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning
This is one of the few Spring Boot configuration parameters that produces a warning if not explicitly set.
This can be seen as a sign that there is no single right choice.
I nevertheless think choosing false is the correct decision for most applications,
but I respect a developer who can make a reasoned argument that true adds value for a particular application.
The question boils down to whether OSIV is a good thing or not, and why.
When set to true, OSIV is enabled: a JPA EntityManager instance (and so a Hibernate session)
is automatically created by Spring to wrap the whole web request.
This means that lazy-loaded associations can be accessed outside the transactions often declared
at the level of your business services.
As long as the loaded entities are within the scope of their EntityManager, they are in the MANAGED state.
This means that you can safely access associations that have not been loaded yet.
This greatly reduces the risk of LazyInitializationException in your controllers, views or when Spring uses Jackson
to serialize the beans returned by your REST controllers to JSON.
It also simplifies application development, because you don't have to pre-fetch the required associations.
This looks convenient and useful, but it has significant downsides.
First, it brings uncontrolled and possibly poorly performing database access outside your application logic.
Uncontrolled means that it can trigger database access that developers may not have anticipated. For example, some applications directly return JPA entities in REST controllers. In this case, as the domain model evolves and more associations are added to the entities, the REST controllers may trigger more and more database queries without developers realizing it.
Poorly performing means that it could trigger N+1 select problems, and severely degrade the performance of your application. But even besides N+1 select problems, lazy-loaded data come from additional queries that slow down the application and consume extra database resources.
It's a slippery slope that accumulates technical debt over time. Once OSIV has been used for a while,
disabling it could cause many LazyInitializationException errors and require significant code rework.
It also increases the database connection pool usage since connections are borrowed for a longer duration.
I think that it defaults to true because it is the most convenient option for beginners to avoid
frustrating LazyInitializationException.
Instead, I usually recommend to disable OSIV by setting the parameter to false:
spring.jpa.open-in-view=false
As a consequence, no EntityManager instance will wrap the web requests.
Lazy-loading of data will only work within the transactions declared on your application components.
When the transaction ends, the loaded entities become DETACHED and lazy-loading is no longer possible.
You will get LazyInitializationException if lazy-loading is attempted outside of these transactions.
But once again, lazy-loading causes additional database calls that can degrade application performance.
To fix these LazyInitializationException errors, you may be tempted to use eager relations, but this is usually
a bad idea because most of the time, Hibernate will load more data than you actually need, using inefficient queries.
Prefer using lazy relations and, on a case-by-case basis, think about the data you need to load and load them efficiently. For example, load the required data, convert the entities to DTOs (or consider using projections), and return those DTOs from your REST controller methods.
Fortunately, JPA supports several techniques to optimize the loading of data such as JOIN FETCH or entity graphs.
See my Faster JPA relations loading dedicated article for additional information.
I will give one example. Consider a @ManyToOne relation from Car to Owner. If you need to load all cars and
for each car the corresponding owner, you can use a JOIN FETCH to load all data in a single query
instead of 1+N (one for all cars + one for each distinct owner):
@Repository
public interface CarRepository extends JpaRepository<Car, Long> {
// Returns the cars and their owner using 1 query instead of 1+N
@Query("SELECT c FROM Car c JOIN FETCH c.owner")
List<Car> findAllWithOwners();
}
Asking about the Open Session In View pattern reveals a developer's knowledge about several major aspects of Spring application development.
Understanding it, and why Spring warns you about it, is a mark of a developer who thinks beyond making things work, to making them work well.
In most applications, setting it to false is a safer choice. It forces you to own your data-loading strategy.
© 2007-2026 Florian Beaufumé