Concurrent Object Prefetching with Afluentes Saulo Medeiros de Araujo, Nelson Souto Rosa, Kiev Santos da Gama, Silvio Lemos Meira Centro de Informática Universidade Federal de Pernambuco Recife, Brazil {sma2, nsr, kiev, srlm}@cin.ufpe.br Abstract —Prefetching is an effective strategy to reduce the latency when a system transfers data between different memory hierarchy levels. The prefetching performed by ORMs (Object-Relational Mapping) frameworks consists in executing queries that result in data of multiple objects. Existing ORMs usually execute these queries sequentially. In this context, this paper introduces LIToRAL, a DSL (Domain Specific Language) that allows programmers to declare which objects a system will require when processing a request. In addition to the proposed DSL, we show how to interpret LIToRAL programs with Afluentes, a framework for developing I/O intensive systems in Java. In order to evaluate the proposed approach, we compare the time required to prefetch objects by sequential and concurrent query execution as performed by ORMs and LIToRAL/Afluentes, respectively. In addition to the observed performance gain, the code that uses the LIToRAL interpreter is significantly smaller and simpler than the code that uses Afluentes directly. Keywords-object relational mapping; concurrent prefetching; domain specific language I. INTRODUCTION Object-Relational Mapping frameworks (hereinafter referred to as ORMs) significantly reduce the effort required to implement the persistence layer of systems that interact with relational databases. In practice, ORMs allow persistent objects (stored in secondary memory) to be handled like transient objects (stored in primary memory). However, such transparency is not complete. In particular, the time taken for accessing a persistent object is several orders of magnitude higher than accessing a transient one. This is not only because the primary memory is faster than the secondary one, but it is also because the latency of the former is much lower than the latter. Furthermore, ORMs and databases are typically deployed on separate computers connected through a local area network. In these cases, the network increases the latency in such way that reduces or even cancels the benefits of disk block caching and prefetching performed by database management and operating systems. Prefetching is an effective strategy to reduce the time spent on the latency. In the context of ORMs, it consists in executing queries that result in data of multiple objects rather than just one. Existing work on prefetching 1 in ORMs 1 Existing work on prefetching in ORMs assign different meanings to this term: (1) a method for speculating which objects a system will [18][20][21][22] present the many strategies (e.g., inner and outer joins, unions, subselects, temporary tables) by which a single query results in data from multiple objects and discuss their relative merits. ORMs, however, usually execute these queries sequentially. In this paper, we introduce the LIToRAL Domain Specific Language (DSL) [1] that allows programmers to declare, independent from persistence details, which objects a system will require when processing a request. Meanwhile, we also show how to interpret LIToRAL programs with Afluentes [3], a framework for developing I/O intensive systems in Java. At the end, this approach has a key role in increasing ORM prefetching performance by executing queries concurrently. Although our contribution can be discussed and evaluated from the perspective of other phases of the DSL development (e.g., decision, analysis, design and deployment) [2], in this paper, we focus on the construction of the LIToRAL interpreter with Afluentes. We evaluated our proposal through experiments in which objects mapped into a relational database were prefetched with sequential and concurrent query execution. We implemented the latter with the LIToRAL interpreter and also directly with Afluentes. The experiments showed two main benefits:  quantitative – the concurrent query execution reduced the mean prefetch time observed in the sequential execution in 20% (worst case) and 45% (best case);  qualitative – the code that uses the LIToRAL interpreter is significantly smaller and simpler than the code that uses Afluentes directly and interpretation overhead is negligible. Some work on prefetching in ORMs have differing opinions about the advantages and disadvantages of having a programmer explicitly declaring which objects a system will require when processing a request. [22] claims that the cost of having an expert programmer providing this information is low, and the benefit it brings to the performance of a system is high. By contrast, [20] and [21] argue that the reuse of code makes it difficult to provide such information correctly. They claim that ORMs must speculate what objects they will prefetch. On the other hand, [29] argues that require when processing a request; (2) a strategy to retrieve data from multiple objects in a single query. In this work, we assign (2) to the prefetching term and we call it speculative when information produced by (1) drives it.