Article Preview
TopIntroduction
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 Approach | Thread-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
} |