Evolution and Revolutions in LDAP Directory Caches

Efficient evaluation of preference query processes using twig caches

“…We adopt the profit metric introduced in [6], considering a KNAPSACK problem that selects elements in decreasing order of benefit/size. We then slightly customize the model to suit our application.…”

“…Since the query in Figure 2(b) draws more benefit from the cached data, we pose it next. While evaluating the query plan, a structural join SJ 6 (offer,location) is admitted into the cache, but join SJ 7 is discarded, because it is not beneficialfor future queries. After finishing the query, the meta-data ofthe cache is updated for the next round as shown in Figure 5(1), i.e., in the Ref field, the current query (b) is simply deleted from SJ 1 and SJ 3 joins.…”

“…Since the total benefit of the two joins SJ 4 and SJ 6 is lower than that of SJ 8 , they are replaced. In contrast, the join result of SJ 9 , whose benefit is lower than any cached join, is not admitted.…”

“…When the next two queries in Figure 2(g) and (h) are considered, the query in Figure 2(g) whose evaluation plan is shown in Figure 5 (6), is chosen to be evaluated first. Only SJ 14 whose benefit is zero for subsequent queries is removed from the twig cache.…”

Predicting Data Access Patterns in Object-Oriented Applications Based on Markov Chains

“…That enables the loading of data that would be needed by the application in a pre-emptive fashion (prefetching it), effectively reducing the time lost while waiting for the data to be loaded on demand. Other works related to data accesses and manipulations [3][4][5][6][7][8][9], loading and prefetching [10][11][12][13][14][15][16][17][18] and caching can be seen in [19][20][21][22][23][24][25][26][27][28].…”