Blockchain-based Model for Social Transactions Processing

Idrissa Sarr1, Hubert Naacke2 and Ibrahima Gueye1

1Universite Cheikh Anta Diop, LID, BP. 16432, Dakar-Fann, Senegal2UPMC Sorbonne Universites, LIP6, 4, place Jussieu 75005, Paris, France

Keywords: Transaction Processing, Load-aware Query Routing, Data Consistency.

Abstract: The goal of this work in progress is to handle transactions of social applications by using their access classes.Basically, social users access simultaneously to a small piece of data owned by a user or a few ones. Forinstance, a new post of a Facebook user can create the reactions of most of his/her friends, and each of suchreactions is related to the same data. Thus, grouping or chaining transactions that require the same accessclasses may reduce significantly the response time since several transactions are executed in one shot whileensuring consistency as well as minimizing the number of access to the persistent data storage. With thisinsight, we propose a middleware-based transaction scheduler that uses various strategies to chain transactionsbased on their access classes. The key novelties lie in (1) our distributed transaction scheduling devised on topof a ring to ensure communication when chaining transactions and (2) our ability to deal with multi-partitionstransactions. The scheduling phase is based on Blockchain principle, which means in our context to recordall transactions requiring the same access class into a master list in order to ensure consistency and to planefficiently their processing. We designed and simulated our approach using SimJava and preliminary resultsshow interesting and promising results.

1 INTRODUCTION

Generally, social applications are read intensive what-soever the write operations are so important. Forinstance, Facebook may face more than 1.6 billionreads per second and 3 million writes per second dur-ing peak hours. These read and write operations de-rive from users interactions. Users interactions aresequences of transactions and we assume that eachtransaction reads and writes data owned by one orseveral users. Even though, transactions are usuallyshort, the volume of required data is extremely lowregarding the size of the whole database. Moreover,many transactions may attempt to access the samedataset simultaneously (i.e., at the same time), whichgenerates temporal load peaks on some hot data. Sucha situation, more known as a net effect, has the draw-back to slow user interactions.

Furthermore, it is worth noting that among themultiple requirements of social applications one maykeep three: response time, scalability and availability.One way to achieve scalability and availability is topartition data and process independent transactions inparallel manner. However, partitioning data perfectlyin such a way that each transaction fits only on onepartition/node is quite impossible. Thus, multi-nodes

or multi-partition transactions must be managed effi-ciently to avoid compromising the positive effect ofsplitting and/or replicating data. In a context such associal environment multi-partitions transactions mayhappen due to unbounded and unlimited interactionsuser may have with others.

We proposed in STRING (Sarr et al., 2013) ascheduling solution that uses various strategies toorder (or group) transactions based on their accessclasses. The proposed approach for overcoming lim-its in existing solutions, is guided by the fact thatgrouping transactions with similar patterns of data ac-cess might save a significant amount of work. Weleveraged on the ability to process a group of con-current transactions that is faster than processing onetransaction at a time and it reduces the number of mes-sages sent to the database node. More precisely, ifevery application directly connects to the database,then the latter may become a bottleneck and over-loaded. Rather, application requests can be gath-ered and grouped at a middleware stage and thereby,database connection requests are minimized.

The proposed solution works in two steps: ascheduling step followed by an execution step. Thescheduling step aims at grouping all transactions ac-cessing the same data into a block regardless where

309Sarr I., Naacke H. and Gueye I..Blockchain-based Model for Social Transactions Processing.DOI: 10.5220/0005519503090315In Proceedings of 4th International Conference on Data Management Technologies and Applications (DATA-2015), pages 309-315ISBN: 978-989-758-103-8Copyright c 2015 SCITEPRESS (Science and Technology Publications, Lda.)

they are issued. Afterwards, each transaction is ex-ecuted at the nodes storing the required data. How-ever, the grouping mechanism does not guarantee thata group of transactions are executed on the executionlayer while respecting the order in which transactionsare received. That is, the order in which transactionsare sent by the scheduler may differ to the one theexecution layer processes them, which has the draw-back to induce inconsistencies or disorganize the so-cial interactions. Moreover, we have assumed thatmulti-partitions transactions are infrequent and there-fore had not been taken into account deeply.

This work in progress improves our previous solu-tion. It aims at handling more efficiently multi parti-tion transactions. It relies on a smarter description ofthe transactions requests, which allows for globallyordering concurrent transactions while providing ef-ficient decentralized transaction execution. The mainidea is to avoid imposing any specific ordering rules(such as processing multi-partition transactions be-fore single-partition ones, or vice-versa) as it is pro-posed in previous work. Such ordering would unnec-essarily delay some transactions. On the opposite, weaim to order the transaction as close as possible to the”natural” ordering of the requests that are submittedto the system. Therefore, considering the local order-ing of transactions arriving at each node of the sys-tem, we propose to describe them in a smart way toobtain a global ordering which is expected to bring amore efficient execution. Then, each node could fol-low that ordering to execute transactions efficiently anconsistently.

With this in mind, transactions are ordered duringthe scheduling step in such a way that each transac-tion is followed or preceded by another one as in ablockchain model. Blockchain is a mechanism to val-idate the payment processing with Bitcoin currency(Barber et al., 2012). It states to keep a public transac-tions log shared by all users in order to record bitcoinownership currently as well as in the past. By keepinga record of all transactions, the Blockchain preventsdouble-spending. The key idea of Blockchain is thateach transaction is guaranteed to come after the previ-ous transaction chronologically because the previoustransaction would otherwise not be known. Once atransaction is positioned into the chain, it is quite im-practical to modify its order because every transactionafter would also have to be regenerated. These prop-erties are what make double-spending of bitcoins verydifficult.

Hence, we rely on Blockchain model for two rea-sons : i) ensuring consistency between transactions is-sued from anywhere and ii) being able to chain trans-actions with an order that cannot be changed whatever

the replica on which the group of transactions will beexecuted. More precisely, by using the Blockchain,approach we are able to guarantee that a transactionchain will not be scheduled twice nor executed twicewith a different order.

The remainder of this paper is organized as fol-lows. In Section 2 we review some works connectedto ours. In Section 3 we lay out our architecture ofour solution and the communication model betweenthe different pieces of it. We also describe how trans-actons are chained in blocks an routed. In Section4 the transaction execution model for multi-partitionstransaction. In Section 5 we present the preliminaryresults of our experiments while in Section 6 we con-clude and present our future work.

2 RELATED WORK

Our work is linked to transaction processing for scal-able data stores. Large scale solutions for managingdata are facing a consistency/latency tradeoff as sur-veyed in (Abadi, 2012). Today several solutions relaxconsistency for better latency (Silberstein et al., 2012;Lakshman and Malik, 2010; Vogels, 2009) and do notprovide serializable execution of concurrent transac-tions. Other solutions provide strong consistency butonly allow transactions restricted to a single node (Or-acle, 2014)1 , (Chang et al., 2006).

In a multi-tenant database context we have Elas-TraS (Das et al., 2013), which is a system provid-ing a mechanism to face load peaks and avoid dis-tributed transactions. In fact, ElasTraS uses a datamigration mechanism couple with some load balanc-ing schemes to face load peaks on database nodes.Moreover, ElasTraS uses a static partition mechanismcalled Schema Level partitionning, which staticallygroup data expected to be accessed together in a sin-gle partition and allows to scale at the granularity ofa partition. However, this partitioning scheme is notsuited to the data we face with social media. Elast-TraS uses some transaction semantics similar to theSinfonia ones. Sinfonia (Aguilera et al., 2007) offersmini-transaction abstraction that ensures transactionsemantics on only a small group of operations such asatomic and distributed compare-and-swap (Michaeland Scott, 1995). The idea is to use the two phasesof 2PC to perform simple operations. Operations arepiggy-backed to the messages sent during the firstphase of 2PC. The operations must be such that eachparticipating site can execute them and respond witha commit or abort vote. The lightweight nature of a

1http://docs.oracle.com/cd/NOSQL/html/

DATA�2015�-�4th�International�Conference�on�Data�Management�Technologies�and�Applications

310

mini-transaction allows the system to scale. In Sinfo-nia, no attempt has been made to absorb load peaks.

DORA (Pandis et al., 2010) is a system that de-composes each transaction to smaller actions and as-signs actions to threads based on their access classes.This design is motivated by the need of avoiding thecontention due to centralized lock manager. DORApromotes local-data access, since each thread towhich is assigned some actions, requires as infre-quently as possible the centralized lock manager. Infact, DORA is a locking-based system that partitionsdata and locks among cores, eliminating long chainsof lock waiting to a centralized lock manager. Themain problem of this design (partitioning) is that theperformances of DORA can be worsen when we facetransactions that access to many partitions. However,the authors of DORA propose PLP (Pandis et al.,2011), a work following DORA and in which theypropose a mechanism to face transactions accessingto many partitions. In fact, they propose in PLP to or-ganize the partitions through trees in such a way thata tree is managed by a single thread. However, evenif this strategy mitigates the impact of transactions ac-cessing many partitions, it still uses a contention pointdue to the necessity of maintaining a centralized rout-ing table.

Finally, the two steps approach we propose forprocessing transactions has been demonstrated to beefficient for write intensive workloads made of shorttransactions (Thomson et al., 2012; Kallman et al.,2008). However, existing solutions following this ap-proach assume that the workload is mostly composedof single node transactions (i.e. they mostly accessindependent data). Most of existing solutions are notdesigned to face a load peak of concurrent transac-tions. In such situation, they would suffer from com-munication overhead and high latency. Our work alsorelies on sequencing and scheduling to guaranty con-sistent processing of multi-node transactions, whilebetter supporting high peak load.

3 SYSTEM OVERVIEW

The architecture is designed with two layers: thescheduling layer and the storage one (see Figure 1).The scheduling layer is made of a set of nodes calledscheduling nodes (SN) while the execution layer con-tains execution nodes (XN) that rely on a datastorethat we consider as a black-box. The motivation ofdoing so is to be able to tie our solution to any data-store that affords interfaces to manipulate data. Asone can see, transactions may be sent to any pointand afterwards they are gathered based on their ac-

cess classes for execution. For example, transactionsTB, TBC and TAC are grouped on the first SN1 even ifthey were received by SN2 and SNk. Moreover, it isworth-noting that SN nodes are structured over a ringfor easing their collaboration.

Figure 1: The layered architecture.

3.1 The Scheduling Layer

The scheduling layer is responsible to absorb the loadpeaks and serves as a front-end that isolates the under-lying datastore nodes from the input load peak. TheSN nodes that compose the scheduling layer receiveany transaction request from applications or possiblyfrom other SN nodes. Once transactions are received,SN nodes build a master list that records all trans-actions happening within a time window. The mas-ter list is a graph that contains two kind of informa-tion, namely, which transaction precedes another one,and what is the access class of each transaction. Fig-ure 2(a) represents the master list of transactions de-scribed in Figure 1. One can see that TA is the genesistransaction, i.e., it is the first transaction on the list andit requires the access class A represented by the yel-low square. Rather, TAB requires two access classes Aand B. In other words, a master list may hold trans-actions of different access classes. It is worth notingthat each SN node maintains a master list that con-tains only transactions it receives from either the ap-plications or its peers. That is, a transaction is exactlylinked to one and only one master list, and when aSN node sends a transaction to another SN node, itremoves it from its master list.

After the master list is established, the SN nodeidentifies the different blocks that compose it. Eachblock is related to one access class. Figure 2(b) de-picts the different blocks of the master list of Fig-ure 2(a). BlockA groups the transactions requiring theaccess class A, while BlockB and BlockC are respec-tively related to access classes B and C. For instance,BlockA = fTA, TAB, TACg, BlockB = fTAB, TB, TBCg,and BlockC = fTBC, TACg. Moreover, one can see that

Blockchain-based�Model�for�Social�Transactions�Processing

311

(a) Master List (b) Blocks of the Master List

Figure 2: Master List and Blocks.

the blocks are linked between them, which means thatsome transactions are requiring more than an accessclass. Hence, we observe that TAB, TBC, TAC requireseveral access classes in the example described in Fig-ure 2(b).

Furthermore, the number of queries that a SN re-ceives must remain bounded. To this end, we effi-ciently balance the load over all SNs regardless of thedata requested by a transaction. We finally assess thenumber of SNs according to the entire workload sub-mitted to the system, expressed in number of clients,and according to the number of transaction requeststhat a SN is able to handle in a unit of time.

3.2 The Storage Layer

This layer is a set of nodes called execution node(XN) that access directly to black-boxed datastore.Each XN node manages the access class that is a par-tition stored via the datastore. Plus, the XN node exe-cutes the block of transactions that are linked to them.Since transactions are ordered in a serial way withina block, the concurrency is already controlled at thescheduling layer. Therefore, the XNs guarantee con-sistent execution of transactions without locking. TheXN node chosen for executing a block is obviouslythe one that is responsible of the access class requiredby transactions within the block. When blocks con-tain transactions requiring several access classes, thusa set of XN nodes are chosen, and Section 3.4 pointsout how the executions are done.

Considering a database divided into n partitionsfp0; p1; :::; pn�1g such that pi \ p j = /0, we assign

each pi to at least one XN and each partition con-stitues a single access class. Each XN may be re-sponsible of more than one partition, i.e., an XN canhold many access classes. In this respect, each SNnode may identify the XN that will be responsible ofa transaction execution once the access class is found.

3.3 Communication Model

As in Blockchain model, transactions are grouped (orchained) and maintained in a decentralized manner.However, we use a more structured communicationmodel than in the Bitcoin protocol where transactionsare broadcasted to all nodes on the network using aflood protocol. In fact, we structure the SN nodesover a ring in such a way that their communicationis directed and unicast. By doing so, we reduce thenetwork overhead and it is more easy to locate whereto send an incoming transaction in order to add it tothe Blockchain list.

Basically, SN nodes are organized into a ring.Each SN node knows its successors and may com-municate with them through a token that is a datastructure. As stated in STRING (Sarr et al., 2013),we handle two distinct tokens: processing token andforwarding token. The processing token is used to se-rialize data access and the forwarding token is used togroup transactions among SN nodes.

3.4 Building the Blocks of Transactions

Transactions are received by SNs, which handle thembased on their access classes and the system status. Tothis end, a SN node needs to know where the data par-titions are stored and, if such partitions are replicatedon several XN, what is the less overloaded XN. Theexpected benefit is to minimize execution time. Withthis in mind, after receiving a transaction, T , modify-ing the partition pi, a SN may process as follows:� If tpi is under its control, thus the SN reads meta-

data of pi and assess where the T ’s latency will bethe shortest regarding to its execution.

� else, it adds T in the block list till it acquires tpias well as it may decide to forward T to anotherSN for shortening T ’s latency.

When SN1 decides to forward a transaction T to SN2,thus SN2 has to add T to the block list correspondingto the access class of T . SN2 keeps T within a blockuntil it gets tpi .

Briefly, transactions are grouped when SNs for-ward transactions to others in order to reduce waitingtime.

The blocks are built by using the grouping algo-rithms we described in STRING (Sarr et al., 2013).

DATA�2015�-�4th�International�Conference�on�Data�Management�Technologies�and�Applications

312

In that work, we proved that the time-based and ring-based approches produce groups with bigger size.Moreover, in a context where it is only matter of re-ducing the logs or datastore accesses, the time basedis more suited followed by the ring approach. There-fore, we choose to rely on the ring-based approachfor single partition transactions for low latency andthe time-based for multi-partitions transactions to beable to handle them rapidly and to free ressources.

4 DEALING WITHMULTI-PARTITIONTRANSACTIONS

As pointed out early, processing tokens are used tosynchronize concurrent transactions while avoidingstarvation. We describe in the following subsectionshow we manage processing tokens to deal particu-larly multi-partition transactions. When a transac-tion requires several partitions, all corresponding to-kens may be already hold elsewhere and thus, mustbe managed efficiently to shorten the response time.To this end, we propose two approaches to face suchsituations : an eager approach and a lazy one. Theeager approach tries to handle multi-partition transac-tions as soon as possible they arrive, while the lazyapproach delay their execution in order to manage ef-ficiently their requirements in terms of access requestsand to shorten the global latency.

4.1 Eager Approach

The eager approach gives a high priority to multi-partitions transactions. Therefore, once a multi-partitions transaction T is detected within SN1’s mas-ter list, SN1 sends an alert to all other SN nodes toenter in idle time, i.e., SN nodes have to push rapidlythe corresponding tokens to SN1 by suspending theexecution of any transaction requiring the same parti-tion as T .

To this end, the forwarding token is used not onlyfor transferring transactions, but also for notifying SNnodes to not use any token required for handling T .Moreover, each SN manages its own forwarding to-ken and we rely on the time-based grouping algorithmwhen forwarding transactions. To detail the steps fol-lowed when handling a multi-partition transaction, weconsider the Figure 3. Assume that SN4 receives amulti-partition transaction requiring both pi and p j.Thus, it identifies the SNs ( SN6 and SN2 respec-tively) holding the processing tokens tpi (green dia-mond) and tp j (blue diamond). Once this identifica-

Figure 3: Inquiring several processing tokens.

tion done, SN4 sends a specific message, called aninhibiting message, by using its forwarding token toSN6 and SN2. An inhibiting message states that allsuccessors of SN6 and SN2 must not use (or hold)tpi and tp j even if they have in their pending list sometransactions related to pi and p j. That is, SN4 inhibitssuccessors of SN6 and SN2 and will be the next oneto hold and allowed to use both tokens tpi and tp j .The intuition behind such a strategy is to give priorityto multi-partition transactions that are somewhat lessfrequent. Moreover, when a successor is inhibited, ithas to forward transactions in its pending list by us-ing the grouping algorithm. In other words, the in-hibiting process leads to group transactions and thus,to shorten their execution time as pointed out earlier.However, when the number of multi-partition trans-actions becomes high, single transactions may sufferfrom starvation, and the response time is lengthened.To avoid starvation in case of a subsequent arrival ofmulti-partitions we propose a lazy approach that wedescribe in next section.

4.2 Lazy Approach

The lazy approach introduces a certain asymmetry inthe SN nodes roles. In fact, one of the SN node is re-sponsible of gathering and routing all multi-partitionstransactions happening within a time window. It actslike a leader node regarding to other SN nodes thathave to send to it all multi-partitions transactions theyreceived. A time window lasts as long as the timerequired for a token to complete a round over thering. This role of leading the execution of all multi-partitions transactions is not given statically to a givenSN, but in a round robin fashion to all SN nodes.That is, a SN node gives the leader role to its suc-cessor once it finishes to route multi-partitions trans-actions received within a time period. The main rea-son of doing so is to balance the overall workload onall SN nodes and to avoid single point of failure fora kind of transactions. This approach uses only oneforwarding token as in the ring-based algorithm de-scribed in (Sarr et al., 2013). The forwarding token

Blockchain-based�Model�for�Social�Transactions�Processing

313

transfers multi-partitions transactions to the SN nodeleader. To explain step by step how the work is done,let us assume that SN0 comes just to be elected as theleader. That is, the forwarding token is picking upmulti-partitions transactions from SN1, SN2 and soon. Unless the forwarding token reaches again SN0,each SN nodes removes every multi-partition transac-tion from its master list and adds it to the token. Atthe end of the time window, i.e., the token is at SN0,the leader requisitions all tokens required for process-ing multi-partition transactions. It is worth noting thata leader may predict the remaining time to get backthe forwarding token. Moreover, it can start gather-ing the processing tokens related to the transactionsthat it has directly received from client applicationnodes before the forwarding token brings to it the re-maining multi-partition transactions. This predictionis possible thanks to our time-based algorithm and iteases/accelerates the tokens requisition process.

The drawback of this approach is that the execu-tion orders may differ from submission orders. Actu-ally, between the reception of a multi-partition trans-action and its execution, others single transactionsmay arrived and handled by others SN. However,since the delay between a reception and the process-ing of a transaction is short, even though with the lazyapproach, it is worth noting that the number of in-coming concurrent transactions is low. In the realmof social applications, this approach is suited sinceconflictual transactions are infrequent and the orderof some interactions (say comments or Like) is notimportant.

5 VALIDATION

In this section we validate our approach through sim-ulation by using SimJava (Howell and Mcnab, 1998),which is a toolkit (API Java) for building workingmodels of complex systems. It is based on discreteevents simulation kernel and includes facilities forrepresenting simulation objects. We implement eachof entities such as clients, SN nodes and XN nodes.Each entity is embedded into a thread and exchangeswith others through events. To be as close as possibleto a real system, each client that sends a query has towait results before sending another one. To balanceclient requests over all SN nodes, clients use a roundrobin fashion to send a query to an SN node.

The main objective of our experiments is to assessthe performances of our solution. To this end, experi-ments were conducted on an Intel duo core with 2 GBof RAM and 3.2 GHz running under Windows 7.

5.1 Evaluating Multi-partitionsTransaction Latency

The main goal of this experiment is to evaluate andcompare the two mechanisms proposed for facingmulti-partitions transactions. We compare the two ap-proaches in terms of latency as well as in terms ofoverhead. To this end, we set 10 SN nodes, 10 XNnodes (i.e. 10 partitions) and we vary the number ofclients from 100 to 600. Moreover, we set a concur-rency rate of 30% and 50% of transactions are multi-partitions. Figure 4 depicts the average response timewhen the workload increases. As one can see, theresponse time grows slightly and remains low for asmall workload and it increases more rapidly whenthe workload becomes heavy. This is true for bothapproaches, either the eager approach or the lazy one.

Figure 4: Response time vs. number of XN (or number oftokens).

However, the response time of the lazy approach stayslow compared to the response time of the eager ver-sion. The main reason is that in the eager version, theSN nodes alternate the execution of the single transac-tions and the one of multi-partitions transactions. Ba-sically, the execution of each multi-partitions trans-action requires to suspend most of the single trans-actions, thus, when the number of multi-partitions isimportant, the waiting time of single transactions in-creases. The effect of this situation is attenuated in thelazy version where most of the single transactions areexecuted before the multi-partitions transactions aregrouped and handled in a shot. In the lazy strategy, al-most all tokens are available since single transactionsare already proccessed before the leader starts execut-ing multi-partitions transactions. Therefore, the over-all response time is less important than in the eagerversion.

DATA�2015�-�4th�International�Conference�on�Data�Management�Technologies�and�Applications

314

5.2 Overhead of the Eager and LazyApproaches

Furthermore, we carried out an experiment to mea-sure the network overhead of our solution, and toidentify which approach costs more in terms of mes-sages. We use the same configuration as previously,i.e., we consider 10 SN nodes, 10 XN and a concur-rency rate of 30%. We report in Figure 5 the resultsthat unveil the high number of messages used by theeager approach where the lazy one requires less mes-sages. This is due to the fact that the eager approachgenerates a set of messages for each multi-partitionstransactions while the lazy waits a time window andaggregates/optimizes the total messages to send forrouting and processing transactions.

Figure 5: Number of messages vs. number of XN (or num-ber of tokens).

6 CONCLUSION

In this paper, we propose blockchain-based model forrouting social transactions. It is a two steps approach:a scheduling step followed by an execution step. Thetransactions are ordered during the scheduling step insuch a way that each transaction is followed or pre-ceded by another one within a block and based ontheir access class. Afterwards, each block of trans-actions is executed at the nodes storing the requireddata. Once a block is sent for execution, it remainsunchanged and hence, the execution order stays iden-tical for all the nodes involved. To reach our goal, werely on the algorithms proposed in our previous works(Sarr et al., 2013) to reduce the communication cost.Moreover, we propose a lightweight concurrency con-trol by using tokens that serve to synchronize simul-taneous access to the same data. We focus speciallyon the case in which transactions require several ac-

cess classes. We designed and simulated our solu-tion using SimJava and we ran a set of experiments.Ongoing works are conducted to evaluate completelyour solution in a cloud platform and to manage grouptransactions size for optimal execution.

REFERENCESAbadi, D. (2012). Consistency tradeoffs in modern dis-

tributed database system design: Cap is only part ofthe story. IEEE Computer, 45(2):37–42.

Aguilera, M. K., Merchant, A., Shah, M., Veitch, A., andKaramanolis, C. (2007). Sinfonia: a new paradigm forbuilding scalable distributed systems. SIGOPS Oper.Syst. Rev., 41(6):159–174.

Barber, S., Boyen, X., Shi, E., and Uzun, E. (2012). Bitterto better — how to make bitcoin a better currency. InFCDS, volume 7397 of LNCS, pages 399–414.

Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach,D. A., Burrows, M., Chandra, T., Fikes, A., and Gru-ber, R. E. (2006). Bigtable: a distributed storage sys-tem for structured data. In USENIX OSDI, pages 15–15.

Das, S., Agrawal, D., and El Abbadi, A. (2013). Elastras:An elastic, scalable, and self-managing transactionaldatabase for the cloud. ACM TODS, 38(1):5–45.

Howell, F. and Mcnab, R. (1998). simjava: A discrete eventsimulation library for java. In ICWMS, pages 51–56.

Kallman, R., Kimura, H., Natkins, J., Pavlo, A., Rasin, A.,Zdonik, S., Jones, E. P. C., Madden, S., Stonebraker,M., Zhang, Y., Hugg, J., and Abadi, D. J. (2008). H-store: a high-performance, distributed main memorytransaction processing system. Proc. VLDB Endow.,1(2):1496–1499.

Lakshman, A. and Malik, P. (2010). Cassandra: a decen-tralized structured storage system. Operating SystemsReview, 44(2):35–40.

Michael, M. M. and Scott, M. L. (1995). Implementation ofatomic primitives on distributed shared memory mul-tiprocessors. In IEEE HPCA, pages 222–231.

Oracle, C. (Retrieved on November 2014). Oracle nosqldatabase, 11g release 2.

Pandis, I., Johnson, R., Hardavellas, N., and Ailamaki, A.(2010). Data-oriented transaction execution. Proc.VLDB Endow., 3(1-2):928–939.

Pandis, I., Tozun, P., Johnson, R., and Ailamaki, A. (2011).Plp: Page latch-free shared-everything oltp. Proc.VLDB Endow., 4(10):610–621.

Sarr, I., Naacke, H., and Moctar, A. O. M. (2013). STRING:social-transaction routing over a ring. In DEXA, pages319–333.

Silberstein, A., Chen, J., Lomax, D., McMillan, B., Mor-tazavi, M., Narayan, P. P. S., Ramakrishnan, R., andSears, R. (2012). Pnuts in flight: Web-scale data serv-ing at yahoo. IEEE Internet Computing, 16(1):13–23.

Thomson, A., Diamond, T., Weng, S.-C., Ren, K., Shao, P.,and Abadi, D. J. (2012). Calvin: fast distributed trans-actions for partitioned database systems. In SIGMOD,pages 1–12.

Vogels, W. (2009). Eventually consistent. Commun. ACM,52(1):40–44.

Blockchain-based�Model�for�Social�Transactions�Processing

315