Solving LazyInitializationException with sonar rules @Transactional method called from another method doesn’t obtain a transaction

We recently added a feature that allowed direct modification on our content for some client vs using the same path (queues) that the batched content is using.
Our user were really happy with it, but after our team implemented the new feature, we started having some LazyInitializationException.

exception for that problem

org.hibernate.LazyInitializationException: could not initialize proxy [com.company.dbservice.model.Image#1004291143] - no Session
     at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:170)
     at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:310)
     at org.hibernate.proxy.pojo.bytebuddy.ByteBuddyInterceptor.intercept(ByteBuddyInterceptor.java:45)
     at org.hibernate.proxy.ProxyConfiguration$InterceptorDispatcher.intercept(ProxyConfiguration.java:95)
     at com.company.dbservice.model.Image$HibernateProxy$aWvtUHZY.getContent(Unknown Source)
     at com.company.dbservice.search.resolver.ImageResolver.getImageUrl(ImageResolver.java:50)
     at com.company.dbservice.search.resolver.ImageResolver.getContentImageUrl(ImageResolver.java:34)
     …..
     at com.company.dbservice.aop.ReadOnlyRouteInterceptor.proceed(ReadOnlyRouteInterceptor.java)
     at com.company.dbservice.sqs.reader.MessageHandler.processMessage(MessageHandler.java)
     at com.company.dbservice.sqs.reader.MessageHandler.receiveMessage(MessageHandler.java)

After looking at, it those errors seem to keep happening to object in object in object that were not needed anyway so the unnecessary acces were remove to prevent processing these object. It a solution you might say but this don’t solve the underlying issue.
Here an example of the table surrounding the object.

When I look in new relic the next they I notice that the error were still happening.
This time it was for an object that was needed. After some digging, I found out that the new endpoint for the direct route didn’t have the @Transaction annotation. It was calling the same code to save and process the object the batch part was using though.
For those who don’t know @Transactional tells spring to create a proxy around the object. The proxy intercepts calls to the object from other objects. The proxy does not intercept calls within the object.

So to fixed we had to add @Transactional on the method that is invoked from “outside” and it fixed the problem.

Related: Hibernate could not initialize proxy – no Session