Ask Questions and Find Answers

Actually I kind of disagree with Olaf in this case...

The static util classes are definitely "legacy", but they also serve in this case where your model instances are not going to have access to any of the services for this kind of "lazy lookup".

Your NPE does appear to be related to the CustomerLocalServiceUtil not actually having the CustomerLocalService available via the service tracker.

There's lots of reasons this can happen, such as:

The local service is, itself, not yet loaded or exposed, could be a code issue or something preventing the service from being available.

The lookup for the local service by the local service util's service tracker is failing for some reason.

The one thing you didn't mention was what version of Liferay you're using. You might actually be using a version of Liferay w/ a bug for all we know.

All of this being said, you absolutely should ask yourself if you really want to do something like this.

Sure a lazy lookup of the Customer object will seem to make sense, you can pull it and keep it with the order, you don't have multiple retrieves, etc.

There are other problems that you have to consider:

Once you cache the Customer instance, it can be stale since it will not be updated if a Customer data is changed or deleted.

Holding an instance may pose garbage collection issues. You're holding a reference to an object that might otherwise have been GC'd after use but, because of this additional reference, it may not be able to be GC'd.

When there are massive parent-child relationship counts, there can be a lot of these multiple references held for no reason. In your case, how do things feel if you are holding 100 orders and each order has a reference to the same Customer object?

Often times you end up over-thinking an optimization that really isn't necessary at all.

It is perfectly fine for your display code to manually retrieve the Customer instance in the display logic. Liferay uses EhCache to cache objects fetched from the DB, so even the case with 100 orders fetching the Customer 100 times, it really would only be a fetch from the DB once and then feed from the cache 99 other times.

And, since Liferay is tracking changes to entities across the cluster, if someone changes Customer along the way, Customer will be dumped from all of the caches and a pull of the same ID for your order display will be a cache miss and the updated entity will be retrieved from the DB, thus dealing with the stale Customer record issue.

My recommendation: Just don't do it. Unless you have actual performance and load test results which show your way is better than just retrieving using the API, 99% of the time your code is going to have bugs and will not offer any measurable performance improvement at all.

KISS and everything will just work.

This statement is very interesting. Can you explain this a bit more? You example is great. We have 100 Orders with 100 different customers. I will output the orders in a HTML table with structure:

orderId                 orderDescription                 customerName

I will get the 100 Orders in one query. Ok so far. I will loop the orders and I have to get for each order the customer object through the service. In total this will cost me 200 queries. Am I wrong? Is there a better way? How to achieve " fetching 100 customers together with the 100 orders"?

If you fetch 100 orders in 1 query, and then 100 customers in 100 queries, you end up with 101 queries, not 200. But the main point is that the number of queries depends on the number of records retrieved - something that might not be detected in testing with a handful of objects, but be really detrimental in production systems once you deal with enough data to become painful and hard to reproduce in test systems.

I can't tell what the ideal architecture is, just provide some alternatives:

* You might not need the full entity objects to "just" show partial information
* You might want to implement paging, so that you only show (for example) 20 objects at once. Then determine if 21 queries are prohibitive or not. These are limited by the paging size, not by the number of the retrieved objects
* I'll admit: I'm not sure if ServiceBuilder is able to pre-populate the customer objects out of the box. But you could do so by utilizing another query fetching all referenced customers (at least into cache) by utilizing a dynamic query on Customer providing it with all referenced customerIDs (resulting in the single query - pseudo-sql - "SELECT ... from Customer WHERE customerID IN ....."). This way you'll end up with 2 queries: One on Order, one on Customer. No matter how many objects you fetch.