CODEWITHSUNDEEP
javaspringhibernate
akourt
akourt

Reputation: 5563

@Transactional annotation Spring boot 2.0 and hibernate LazyInitializationException

I have the following question. From what I understand the @Transactional annotation is supposed to keep the session alive, thus enabling to lazy fetch child entities without the need to performe a specific joining query.

I have the following scenario where I do not understand why I'm still getting a LazyInitializationException.

My app runs a resolver in order to provide the various controller services with a resolved object so that it can be used directly.

Said resolver intercepts a header from the request and using it's value attempts to query the db in order to fetch the object. Now the object in question is quite simple is it's doings albeit it has a list of two sub-entities.

In order to perform the resolving action I'm using an extra service where I basically wrap some JpaRepository methods. The complete is below:

@Service
public class AppClientServiceImpl implements AppClientService {

    private static final Logger LOGGER = LoggerFactory.getLogger(AppClientServiceImpl.class.getCanonicalName());

    private final AppClientRepository repository;

    @Autowired
    public AppClientServiceImpl(AppClientRepository repository) {
    this.repository = repository;
    }

    @Override
    @Transactional(readOnly = true)
    public AppClient getByAppClientId(final String appClientId) {
        LOGGER.debug("Attempting to retrieve appClient with id:: {}", appClientId);
    return repository.findByAppClientId(appClientId);
    }

    @Override
    @Transactional
    public void saveAndFlush(final AppClient appClient) {
        LOGGER.debug("Attempting to save/update appClient:: {}", appClient);
    repository.saveAndFlush(appClient);
    }

}

As you can see both methods are annotated as @Transactional meaning that the should keep the session alive in the context of that said method.

Now, my main questions are the following:

1) Using the debugger I'm seeing even on that level getByAppClientId the list containing on the sub-entities which is lazy loaded has been resolved just fine.

2) On the resolver itself, where the object has been received from the delegating method, the list fails to be evaluated due to a LazyInitializationException.

3) Finally on the final controller service method which is also marked as @Transactional, the same as above occurs meaning that this eventually fails to it's job (since it's performing a get of the list that has failed to initialize.

Based on all the above, I would like to know what is the best approach in handling this. For once I do not want to use an Eager fetching type and I would also like to avoid using fetch queries. Also marking my resolver as @Transactional thus keeping the session open there as well is also out of the question.

I though that since the @Transactional would keep the session open, thus enabling the final service method to obtain the list of sub-entities. This seems not to be the case.

Based on all the above it seems that I need a way for the final service method that gets call (which needs the list on hand) to fetch it somehow.

What would the best approach to handle this? I've read quite a few posts here, but I cannot make out which is the most accepted methods as of Spring boot 2.0 and hibernate 5.

Update:

Seems that annotating the sub-entitie with the following:

@Fetch(FetchMode.SELECT) @LazyCollection(LazyCollectionOption.TRUE)

Resolves the problem but I still don't know whether this is the best approach.

Upvotes: 0

Views: 403

Answers (1)

Christian Beikov
Christian Beikov

Reputation: 16452

You initialize the collection by debugging. The debugger usually represents collections in a special way by using the collection methods which trigger the initialization, so that might be the reason why it seems to work fine during debugging. I suppose the resolver runs outside of the scope of the getByAppClientId? At that point the session is closed which is why you see the exception.

I created Blaze-Persistence Entity Views for exactly that use case. You essentially define DTOs for JPA entities as interfaces and apply them on a query. It supports mapping nested DTOs, collection etc., essentially everything you'd expect and on top of that, it will improve your query performance as it will generate queries fetching just the data that you actually require for the DTOs.

The entity views for your example could look like this

@EntityView(AppClient.class)
interface AppClientDto {
  String getName();
}

Querying could look like this

List<AppClientDto> dtos = entityViewManager.applySetting(
  EntityViewSetting.create(AppClientDto.class),
  criteriaBuilderFactory.create(em, AppClient.class)
).getResultList();

Upvotes: 1

Related Questions