Java Reference
In-Depth Information
The first time the loop is executed with a JOIN query, there is a big performance win: it takes
only 17.9 seconds. That is the result of issuing only one SQL request, rather than 33,409 of
them.
Unfortunately, the next time the code is executed, it still needs that one SQL statement, since
query results are not in the L2 cache. Subsequent executions of the example take 11.4
seconds—because the SQL statement that is executed has the JOIN statement and is retriev-
ing over 200,000 rows of data.
If the JPA provider implements query caching, this is clearly a good time to use it. If no SQL
statements are required during the second execution of the code, only 1.1 seconds are re-
quired on the subsequent executions. Be aware that query caching works only if the paramet-
ers used in the query are exactly the same each time the query is executed.
Avoiding queries
If entities are never retrieved via a query, then after an initial warm-up period, all entities can
be accessed through the L2 cache. The L2 cache can be warmed up by loading all entities, so
slightly modifying the previous example gives this code:
EntityManager em = emf . createEntityManager ();
ArrayList < String > allSymbols = ... all valid symbols ...;
ArrayList < Date > allDates = ... all valid dates ...;
for
for ( String symbol : allSymbols ) {
for
for ( Date date = allDates ) {
StockPrice sp =
em . find ( StockPriceImpl . class , new
new StockPricePK ( symbol , date );
... process sp ...
iif ( processOptions ) {
Collection <? extends
extends StockOptionPrice > options = sp . getOptions ();
... process options ...
}
}
}
The results of executing this code are given in Table 11-6 .
Search WWH ::




Custom Search