Implementation of grasping strategy based on AOP in Java EE application

Typical Java EE applications that use the O/R mapping tool face the problem of getting the data they need through the most streamlined SQL queries. Most of the time it's not easy to do. By default, the O/R mapping tool loads data on demand unless you change its default settings. Deferred load behavior ensures that dependent data is loaded only when it is actually requested, thus avoiding the creation of meaningless objects. Sometimes our business does not use those components that depend on it, and delay loading comes in handy without having to load the unused components.

Typically, our business is very clear about what data is needed. However, due to the use of deferred loading, the performance of the database is reduced when a large number of select queries are performed, because the data required for the business is not obtained at a draught. This can lead to bottlenecks (scalability issues) for applications that need to support a large number of requests.

Let's take an example and assume that a business process wants to get a person and their address information. We configure the address component to delay loading so that you need more SQL queries to get the data you need, that is, first query person and then query address. This increases the cost of communication between the database and the application. The solution is to get both the person and the address in a separate query because we know that both components are required by the business process.

If you develop business-specific FETCHING-API in dao/repository and the underlying service, we have to write different APIs to crawl and assemble for the same domain objects that have different datasets. Doing so would inflate the repository and bottom service and eventually become a maintenance nightmare.

Another problem with deferred fetching is that the database connection is opened until the requested data is fetched, or the application throws a deferred load exception.

Note: If you use prefetch in a query to get the data in level two cache, we will not be able to solve the problem raised above. For hibernate, if we use prefetching to get the data from the level two cache, it will fetch the data from the database, not the cache, even if it is already present in the level two cache. This means that hibernate does not solve this problem, which means that we should not get the object in the level two cache by prefetching in the query.

For the O/R mapping tool, which allows us to adjust the query to get the cached object, if an object in the cache is fetched from the cache, it is taken in a proactive manner. This solves the transaction/db connection problem mentioned above, because the data in the cache is fetched during the execution of the query rather than on demand (that is, deferred loading).

Take a look at the problems and solutions to deferred loading with the example code below. Consider the following scenario: There are 3 entities in a field, namely, employee, department and dependent.

The relationship between the three entities is as follows:

Employee has 0 or more dependents.

Department has 0 or more employees.

The employee belongs to 0 or 1 department.

We're going to do three things:

Get more information about employee.

Get more information about employee and its dependent.

Get more information about employee and its department.