CTSA: Concurrent Tuple Set Architecture Extending Concurrency to Call Level Interfaces

CTSA: Concurrent Tuple Set Architecture Extending Concurrency to Call Level Interfaces

Óscar Mortágua Pereira (Instituto de Telecomunicações, DETI – University of Aveiro, Aveiro, Portugal), Rui L. Aguiar (Instituto de Telecomunicações, DETI – University of Aveiro, Aveiro, Portugal) and Maribel Yasmina Santos (Centro Algoritmi, DSI – University of Minho, Guimarães, Portugal)
Copyright: © 2013 |Pages: 22
DOI: 10.4018/ijsi.2013070102
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

Call Level Interfaces (CLI) provide a set of functionalities to ease the connection between client applications and relational databases. Among them, the management of data retrieved from databases is emphasized. The retrieved data is kept in local memory structures (LMS) that allow client applications to read it and modify it through protocols. They are row (tuple) oriented and, while being executed, they cannot be preempted to start another protocol. This restriction leads to several difficulties when applications need to deal with several tuples at a time, namely in concurrent environments where several threads need to access to the same LMS instance, each one pointing to a different tuple and executing its particular protocol. To overcome this drawback, a Concurrent Tuple Set Architecture (CTSA) is proposed for LMS. A performance assessment is also carried out. The outcome is the evidence that in concurrent environments, the CTSA significantly improve the overall performance.
Article Preview

Introduction

Database applications comprise at least two main components: database components and application components. In our context, application components are developed in the object-oriented paradigm and database components rely on the relational paradigm. The two paradigms are simply too different to bridge seamlessly, leading to difficulties informally known as impedance mismatch (David, 1990). The diverse foundations of both paradigms are a major hindrance for their integration, being an open challenge for more than 50 years (Cook & Ibrahim, 2005). In order to overcome the impedance mismatch issue, several solutions have emerged, such as embedded SQL (SQLJ (Eisenberg & Melton, 1999)), language extensions (LINQ (Erik, Brian, & Gavin, 2006; Kulkarni, Bolognese, Warren, Hejlsberg, & George)), Call Level Interfaces (CLI) (ISO, 2003) (JDBC (Parsian, 2005), ODBC (Microsoft, 1992)), object/relational mappings (O/RM) (Hibernate (Christian & Gavin, 2004), TopLink, LINQ) and persistent frameworks (JDO (Oracle), JPA (Yang, 2010), SDO (IBM), ADO.NET (Mead & Boehm, 2011)) and other solutions that have been proposed the research community, such SQL DOM (Russell & Ingolf, 2005) and Safe Query Objects (William & Siddhartha, 2005). Despite their individual advantages, these solutions have not been designed to manage concurrency on the client side of database applications. Currently, concurrency is managed by database management systems through database transactions. Thus, whenever the same data is needed by different client-threads, each thread behaves as an independent entity requesting its own data set. In other words, instead of providing sharing mechanisms to access data returned by a unique execution of a Select expression, each thread executes a Select expression independently from other threads. This leads to a waste of resources, namely it requires more memory, it requires more power computation, and performance is very probably affected negatively. Current solutions use local memory structures (LMS) to manage the data re-turned by Select expressions. Beyond services to read the data kept by LMS, LMS provide services to execute three additional main protocols on their in-memory data: update data, insert new data and delete data. Thus, client-applications are able to update data, insert data and delete data without the need to explicitly execute Update, Insert and Delete expressions, respectively. Once again, these protocols are not thread-safe, this way not promoting the use of LMS on concurrent environments. Table 1 presents a typical use case where attributes of LMS are updated. The left-side column presents the approach of current solutions (not thread-safe) and the right-side column presents an approach based on thread-safe LMS. When using the current approach, each thread is created and then it runs (doIt) to execute a task. Each thread has its own LMS, this way preventing any concurrency at the LMS level. When using the thread-safe approach, all threads share the same LMS and update the attributes concurrently. In order to overcome the limitations of CLI, this paper proposes a Concurrent Tuple Set Architecture (CTSA). The CTSA, unlike current solutions, provides thread-safe protocols to interact with the data returned by Select expressions, as shown on right column-side of Table 1.

Table 1.
Current and thread-safe approaches
Current ApproachThread-safe LMS
void begin() {
foreach thread
create thread
thread.doIt(PKs)
end
}
void doIt(PKs) {
LMS=execute Select expression
while more rows on the LMS
if PK is in PKs
then update row
move to the next row
end while
}
void begin() {
LMS=execute Select expression
foreach thread
create thread
doIt(LMS,PKs)
end
}
void doIt(LMS, PKs) {
while more rows on the LMS
if PK is in PKs
then update row
move to the next row
end while
}

Complete Article List

Search this Journal:
Reset
Open Access Articles: Forthcoming
Volume 6: 4 Issues (2018): 1 Released, 3 Forthcoming
Volume 5: 4 Issues (2017)
Volume 4: 4 Issues (2016)
Volume 3: 4 Issues (2015)
Volume 2: 4 Issues (2014)
Volume 1: 4 Issues (2013)
View Complete Journal Contents Listing