Spring Boot + Hibernate + Thymeleaf 延迟加载异常

Question

I'm working on a Spring Boot web service but had a problem and don't know how to solve it (I have tried for many days...)

In my DB I have AB and C three tables, the relation is A one to many B, B one to many C.

In my spring boot controller, I need to have a findById() function for table A, when I call this endpoint, the data in A, B and C should be retrieved accordingly.

The data volume in table C is massive, it has 16K records or so.

That is the background.

Now, if I call findById() for table A, the data inside table A loaded perfectly, which is great, however, I can't get data from B and C because of Lazy Loading Exception.

To solve this, I changed the fetch type to EAGER fetch. However, it will take ages to get the data, which is really bad, (I can tell there is no infinity loop, it just because the data volume is large I guess, it usually takes 40 seconds to get the result when I debug it)

Thus, I tried some other stuffs. Since I realised that this project I have multiple db connections, so I add another annotation @Transanctional("transactionName") to restrict the service and Repository only scan the data inside a particular transaction. And it works!

However!!!

this controller is like below:

@Transactional("name")
public String findDataInTableAById(@PathVariable("id") Integer id, Model model)
    {
         ModelA a = tableAService.findById(id);
         model.add("dataInThymeleaf", a);
         return "/path/page.html"
    }

When I put a breakpoint on ModelA a = tableAService.findById(id); I can definitely see all the data loading perfectly in debug console. However, when I give it to my front-end (Thymeleaf), it gives me a Lazy Loading Exception again. I did some research, and I guess it's because the session is already closed before I pass it to Thymeleaf.

Want to know if anyone had the same problem and how to solve it?

Answer 1

TL;DR - try forcing the lazy loading to occur within your method by accessing the fields that are marked as lazy. That would be somehting like a.getB().size(); a.getB().getC().size(); a.getB().size(); a.getB().getC().size(); before the model.add() line. This will load the lazy data within the transaction and will avoid the exception, but I'm pretty sure it won't make things any faster. Here's why:

First of all, this is a purely JPA matter, Thymeleaf has nothing to do with the problem, and Spring itself probably also does not (although it can make things worse, if used improperly).

As you already mentioned, this is a LAZY vs. EAGER issue. Lazy loading means that dependent entities ( @OneToMany , or whatever) are only loaded if needed, at the time they are accessed, instead of at query time. There are a couple of important things to note/understand about this:

• In sum, lazy loading is actually (marginally) slower that loading eagerly. It will make your initial query finish faster, and so you will get some data sooner, but if you then need to lazy-load associated entries, the total loading time will be a little more than if you had loaded them directly in the first place.

• Therefore, lazy loading only makes sense if there is a good chance that you will not need those entries at all for some executions of your code. If you will definitely need them, just later, then don't use lazy loading.

• Another important restriction - lazy loading can only occur in the same transaction/session in which the parent entities were loaded. After the transaction is committed/rolled back, you can't load any more data out of that result list.

In your case, the last point is the problem. Your GUI/templating engine is trying to access lists that are lazy loaded, however by the time they access it, the session is closed.

There is no way around this than to actually load the data while the session is open, which means within the method you cited above. Technically it doesn't matter if you load lazily or eagerly, but you won't get any performance improvement if you do it lazily.

And one more thing that surprises me - you say your table C is "massive" and has 16K records. If you mean 16 thousand, then this is nothing. A massive table is if it has 16 billion entries. 16 million is also large, but not massive. Anything below a couple million entries should be handled almost instantaneously by any DB on current hardware.

This makes me think that your problem might be somewhere else. If you need 40 seconds to run a query on this small scale of data, then this is not normal, no matter lazy or eager loading.