RT-ETM: Toward Analysis and Formalizing Transaction and Data Models in Realtime Databases

F-RT-ETM: Toward Analysis and Formalizing

Real time Transaction and Data in Real-time

Database

Mourad Kaddes1,2, Majed Abdouli1, Laurent Amanton2, Mouez Ali1, RafikBouaziz1, and Bruno Sadeg2

1 Multimedia, Information Systems and Advanced Computing Laboratory, Sfaxuniversity, Route de Tunis km 10 PB 242, 3021 Sakeit Ezzeit, TUNISIA.mourad.kaddes, majed.abdouli, mouez.ali, [email protected]

2 UFR Sciences et Techniques, Universite du Havre, 25 rue Philippe Lebon BP 540,76058 Le Havre Cedex, FRANCE.

laurent.amanton, [email protected]

Abstract. Due to the diversity of extended transaction models, theirrelative complexity and their lack of formalization, the characterizationand the comparison of these models become delicate. Moreover, thesemodels capture only one subset of interaction which can be found in thespectrum of the possible interactions. In front of this established fact,the framework ACTA was introduced. Our contribution in this field istwofold: (i) we extend ACTA by adding many dependencies for capturinga new interaction between transactions in real time environment, and weextend ACTA to take into account temporal characteristics of real-timedata item (ii) we presented a meta-model that capture concept of anextended real time transaction model by using UML class diagram andits formal description using Z language.

Keywords: Transaction, Real-Time, ACTA, Temporal Data, Data Fresh-ness, Meta-model, Z language

1 Introduction

In a number of real-time applications, e.g., stock trading and traffic control,real-time databases systems (RTDBS) are required to process transactions in atimely fashion using a large number of temporal data, e.g., current stock pricesor traffic sensor data, representing the real world status. RTDBS are best suitedfor manipulating such applications since they also handle both large amounts ofdata and time constraints. In the two last decades, a lot of real-time database re-search has been done where different scheduling protocols, EDF, GEDF, MSF;concurrency protocols 2PL-HP, OCC are proposed. The majority of these re-searches adopt the flat transaction model which remains the simplest and mostcommon either in traditional database or real-time database.

However, in real-time applications, the disconnection, the abort and the re-covery may lead the transactions not to more respect their deadlines even if

all the transactions are initially scheduled. Thus, the new applications wouldprofit advantageously from extended transaction model which relaxed Atomic-ity, Consistency, Isolation and Durability properties. Various extensions to thetraditional model have been proposed referred to herein as extended transactione.g. nested transaction, saga transaction, split/join transaction, adaptable trans-action model. This diversity of the models, their relative complexities and theirlacks of formalism encouraged Chrysanthis et al. [1] to define the frameworkACTA. ACTA is a tool to specify and reason out the effects of transactions onobjects and the interactions between transactions. Specifically, it can be used tospecify the properties of atomic and extended transaction models and to synthe-size new transaction models. However, it has not been used to specify time relatedrequirements which are essential to the specification of real-time databases [2].However, there has been a few works to formalize the properties of transactionsand data in RTDBS. In this paper, based on the ACTA framework, we attemptto overcome this shortcoming.

In this paper, we develop a transaction framework based on ACTA to fa-cilitate the formal description of transaction properties in real-time databases.We present an overview of ACTA and our motivation in section 2. Section 3 ex-tends ACTA formalism to take into account temporal characteristics. Section 4we propose a meta-model, called RT-ETM Meta-model for Real-Time ExtendedTransaction, that captures all concept of extended real-time transaction modelsusing UML. We give a F-RT-ETM formal description of RT-ETM. We concludeour work in section 5.

2 Overview of ACTA

ACTA is not a new model of transactions, but rather a formalism allowing theformal description of properties of the complex transactions. Precisely, usingACTA, we can specify and reason about the effect of transaction on objectsand the interactions between the transactions in a particular model. They areformulated by:

1. The effects of the transactions on each other (see fig1 continuous line).2. The effects of the transactions on the objects which they handle (see fig2

continuous line).

2.1 Effects of the transactions on each other

The dependencies provide a practical manner to simplify and to reason on thebehaviour of the concurrent transactions. In fact, the dependencies describe theeffects of the transactions on other transactions, and represent constraints onpossible stories. By examining the possible effects of the transactions actingones on the ‘others, it is possible to determine the dependencies which can bedeveloped between them.The first two and important dependencies presented in [1] are Commit depen-dency and Abort dependency defined in the following way:

1. Commit Dependency (ti CD tj). If ti and tj are committed, then the commitof tj must precede the commit of ti.

2. Abort Dependency (ti AD tj). If tj aborts, ti has to abort too.

Many others dependencies are added to extend ACTA to expressive more be-havior [3], [4], [5], [6], [7].

2.2 Effects of transaction on objects

A transaction invokes an operation on an object and modifies its state and itsstatute which characterize it. The state of an object is represented by its contents.The status of an object is represented by the synchronisation of informationassociated with the object.A transaction effects on objects are characterized by the set of effects whichare visible to it, the whole conflict operations that it carries out, and the wholeeffects that it delegates to other transactions. ACTA allows to capture theseeffects by introducing three sets (ViewSet, AccessSet, ConflictSet) and by usingthe concept of delegation (cf. Fig 1). In fact, ACTA allows finer control over thevisibility of objects by associating three entities, namely ViewSet, ConflictSetand AccessSet with every transaction. We mean by Visibility the ability of onetransaction to see the effects of another transaction on objects while they areexecuted.

1. The ViewSet contains all the objects potentially accessible to the transac-tion that can be operated by transaction.

2. The ConflictSet contains objects that operations wants access but it isalready accessed by incompatible operations.

3. The AccessSet contains all the objects which are already accessed by atransaction.

4. Delegation: traditionally, the committing or aborting of an operation ispart of the responsibility of the invoker. However, the invoker and the onecommitting operation may be different when a transaction delegates its re-sponsibility to another transaction.

3 Temporal characteristics in ACTA

A great deal of ACTA work concerns the formal description of properties of ex-tended transaction models, such as nested transactions, split/join transactions,transactions in active databases and the synthesis of extended transaction mod-els [1]. Basically, transaction models in non real-time databases are the majorconcern of the past work. Through these last two decades, a lot of work hasbeen done in real-time databases which investigate transaction scheduling inreal-time database systems with transaction and data timing constraints. So,Kaddes et al. [7] have proposed a Real-Time ACTA framework (CRT-ACTA) asan extension of ACTA to specify the transaction and data timing constraints.Unlike RT-ACTA [2], which is based on E-C-A (event-condition-action) model

and deals only with active databases, (CRT-ACTA) deals with all RTDBs. Inthis section, we briefly recall the concept of effects of transactions, we definenew transaction dependencies, and we introduce the new concepts of temporalvalidity, priority and dependencies on occurrence. Then, we deal with effects oftransactions on data, data time constraints and data freshness.

3.1 Temporal characteristics of transactions

The distinction between real-time and non real-time database systems lies in thetiming constraints associated with transactions and data values in a real-timedatabase. In real-time database systems, transactions have to complete beforedeadlines, and they have to read data values which are temporally valid, becausedata values may become stale as time goes by. To reach its goal and to satisfythis constraint, transactions are handled and scheduled by the system accordingto their priority. In other words, a transaction is characterized not only by itseffects on objects and other transactions as we have seen in previous section butalso by temporal validity and priority (cf.Fig1).

Effects of Transaction (ACTA)

View Set Access Set Conflict Set Delegation

On TransactionOn Occurence

PriorityTemporal validity

Transaction

On Objects

Fig. 1. Transaction characteristics and effects

Temporal validity Temporal validity permits to specify the validity intervalof transaction, periodicity of transaction and the type of transaction hard, firmor soft ,i.e., hard transaction must absolutely met it deadline. A firm transactioncan missed it deadline in transient overload firm. A soft transaction can continueeven its deadline is missed.

Priority Priority permits to specify how priority is assigned to transaction.Priority is used in most conflict resolution protocols, so the priority assignmentpolicy plays a crucial role.

Effects of transactions The effects of transaction are divided on three sub-categories: on transaction, on occurrence and on objects.

1. On transaction: Recent researches in real-time transactions in RTDBShave focused on the idea of using imprecise computation results so thattransactions meet their deadlines [6], [8]. In other words, transactions reportsestimate or approximate results when they cannot complete within their timequotas. Transactions are composed of two types of sub-transactions: optionaland required. When required sub-transactions of transaction ti are executed,transaction ti pre-commits. Optional sub-transactions may be aborted dur-ing execution if they do not have enough time to complete. They strive toimprove the result being provided to users. Consequently, pre-committedtransactions will not abort.Due to induction of pre-commit event, transaction relationships and be-haviour between transactions are modified. So, dependencies described inthe preceding section can’t express the new relationships between transac-tions. To fill these deficiencies, we propose many new dependencies for moreexpressiveness of these relationships. In former work, if two transactionsti and tj must commit, we can define only one dependency “ ti CD tj ”.This means that transaction ti can’t commit until tj commits. So with suchdependency, we can’t express the relationships between pre-commit transac-tions. We define following new dependencies for more precision in executionof transaction:

– Pre-Commit dependency (ti PCD tj). Transaction ti can’t pre-commituntil transaction tj pre-commits.

– Strict-Pre-Commit dependency (ti SPCD tj). Transaction ti can’t pre-commit until transaction tj commits.

– Weak-Commit dependency (ti WCD tj). Transaction ti can commit if tjis already pre-committed.

In the same way, we can introduce the pre-commit in the exclusion depen-dency. In the literature, exclusion dependency (ti ED tj) expresses that ti

must abort if tj commits. In real time application it’s preferable to excludethe transaction ti when tj pre-commits to release system. Hence ti are notforced to wait the commit of tj .

– Pre-Exclusive dependency (ti PED tj). If the transaction tj pre-commitsthen ti must abort.

– Pre-Exclusive Pre-Exc(ti, tj). Two transactions ti and tj are excludedmutually iff each transaction develops a relation of pre-exclusive dependencyon the other.

2. On occurrence: The effects of transaction on occurrences are defined bythe dependencies between different occurrences of transactions and permit totake into account the periodicity of transaction. Particularly when a trans-action is repetitive, an occurrence of transaction can depend on the otheroccurrences, e.g., in m-k firm model only m must commit among k occur-rences. If m occurrences are already committed, the remainder occurrencescan be aborted or not initialed [9], [10].So, for taking into account the behaviour between different occurrences of atransaction, we define these dependencies:

– Conditional Not Admit occurrence on Commit Dependency CNADOCD(tji, K, m, [C]): the occurrence i of transaction tj is not admitted if the kprevious occurrences are committed and if condition C is true.– Conditional Aborted Occurrence on Commit Dependency CAOCD (tji, k,m, [C]): the occurrence i of transaction tj is aborted if k precedent occur-rences are committed and if condition C is true. In dynamic systems, suchweb servers and sensor networks with non uniform access patterns, the work-load of RTDB cannot be precisely predicted and, hence, RTDB can becomeoverloaded. As a result, uncontrolled deadline misses may occur during thetransient overloads. So, many researches propose [11] [12] [13] to not admit orto abort an occurrence in some conditions. This will imply modifications onthe behavior of the transactions and their interrelationships. We can drivenew dependencies by applying the concept of conditional dependency onthe previous dependencies and relaxing them. A conditional dependency isnoted as follow: ti (dependency [C]) tj where the condition C is an optionalpart. When condition is mentioned and satisfied the dependency must berespected. If the condition is omitted, the dependency must be respected allthe time.– Conditional Not Admit occurrence on Commit Dependency CNADOCD(tji, K, m, [C]): the occurrence i of transaction tj is not admitted if the kprevious occurrences are committed and if condition C is true.– Conditional Aborted Occurrence on Commit Dependency CAOCD (tji, k,m, [C]): the occurrence i of transaction tj is aborted if k precedent occur-rences are committed and if condition C is true.

3. On objects: The effects of transactions on objects are described by thestates and status of objects (cf. section 3.2).

Before we close this sub section we note that in RTDBS we distinguish twoclasses of transactions: update transactions and user transactions. Where up-date transactions are used to update the values of real-time data in order toreflect the state of real world. We can divide this class in two sub-categories.Sensor transactions, composed by a simple operation, executed periodically andhaving only to write a real-time data item. Recomputation or sporadic have toderive a new data item from basic data items when these later are updated [11].User transactions, representing user requests, arrive aperiodically and may readreal-time data items, and read or write non real-time data items. Each type oftransactions has its own structure and has a different behavior, e.g., differentinteractions with the others transactions and objects. For example, each sensortransaction updates its own data items, so no concurrency control is consideredfor sensor transactions.

3.2 Temporal characteristics of Data

A RTDB is composed of temporal data items and non-temporal data items.These items are both considered as passive components. The non temporal dataitems are found in traditional databases and their validity is not affected as timesgoes by. The temporal data items, which can be sensor data items or derived

data items, represent the states of real-time objects which change continuously[14]. These states may become invalid as time goes by. To reflect these changes,data objects that model the entities need to be updated. Only non temporaldata items are taken into account by ACTA. So, we propose to extend ACTA toconsider temporal characteristics. We categorize data freshness into “databasefreshness” and “perceived freshness”.

1. Database freshness (DF) describes the state of data. In addition, data fresh-ness specifies temporal status and it describes the method of freshness[15].

2. Perceived freshness (PF) is defined for the data accessed by user transactions[15].

Database Freshness is described by 4 components: validity interval, value,methods of freshness and impact on other data.

1. Validity interval: leads to the notion of temporal consistency. Temporalconsistency has two classes:– Absolute-consistency: is the state between the environment and its re-flection in the database. As mentioned earlier, this arises from the need tokeep the controlling system’s view consistent with the actual state of theenvironment.– Relative-consistency: is among data used to derive other data. A RTDBcontains basic data items which record and model a physical real world en-vironment. These basic data items are summarized and correlated to deriveviews. When the environment changes, basic data items are update, andsubsequently view recomputations are triggered [16].To formalize the notion of temporal consistency for continuous objects; wedenote a real-time data item by d (value, avi, timestamp) where value de-notes the current state of d, timestamp denotes the time when the observa-tion relating to d was made and avi denotes d’s absolute validity interval.For discrete data model, e.g. stock price, it is difficult to assign reasonable avidue to sporadic update, the data is considered valid until the new sampling.Hence a data objects values remains unchanged until an update arrives [16].

2. Value: it defines the contents of the data. A data can be imprecise andmulti-versions.– Data error: as we have already mentioned, a RTDBS can become over-loaded and this overload is unpredictable. Hence, many approaches proposethrough the transient overload to discard many update transactions to reducethe workload avoiding consequently the degradation of system and eventu-ally its crash. The discard of update transactions implies a certain degree ofdeviation compared to real-world value and then the decrease of data quality.In order to measure data quality, many researches introduce the notion ofdata error, denoted DE. A data error which gives an indication of how muchthe current value of a data object di stored in the database deviates fromthe corresponding real-world value, given by the latest arrived transactionupdating di. The upper bound of the error is given by the maximum dataerror (MDE). If MDE decreases the number of update transaction discarded

decrease also and the quality of data and user transaction quality increaseand vice versa.– Versioning: the conflict between transactions is one of major factor thatmakes some blocked, or aborted and restarted and thereafter this may leadto the transactions miss deadlines especially, in transient overload. To ad-dress this problem, many approaches proposed a multi-versions data [11].An object is defined by a set of values and can be accessed by many readand write operations which belong to different transactions. So we limit dataaccess conflicts between transactions, enhance the concurrency and limit thedeadline miss ratio.

3. Method of freshness: it is important to guarantee the freshness of dataindependently [17]. Hence many approaches, particularly for derived dataitems, are proposed to guarantee the freshness of data with inducing an ac-ceptable number of triggered recomputation transactions. We can mentiondelayed forced update, periodic update, on demand update and deferred up-date. Similarly, for sensor data, different approaches are proposed to main-tain the freshness, e.g., periodic update, on demand, deferred update. . .

4. Impact on others data: define the set of objects whose values are derivedfrom current object. The change of its value implies the obsolescence ofrelated objects and triggers their recomputation.Fig 2 shows the structural relationship of these components and updatetransactions.

Acces SetConflict Set Delegation VIew Set

Update Transction

Non−temporal Data

Effect of user transactionon objects

Temporal Data

Perceived Freshness Database freshness

Conflict User/Update

Validity interval methodes offreshness

Value Impact on othersData

Error on dataVersioning

Extension to ACTA

Exist in ACTA

Fig. 2. Effects of user and update transactions on temporal and non temporal data

Perceived Freshness describes the effect of a user transaction on real timedata. It is represented by AccessSet, ViewSet, delegation and ConflictUser/UpdateSet. This later describes the conflicts between user and update transactions. Weextend ViewSet and AccessSet by adding temporal constraints to allow finercontrol over the visibility of objects.

1. ViewSet: it contains all the valid objects potentially accessible to the trans-action. It specifies what objects can be operated by the transaction, i.e., thestate of these objects that is visible to the operations invoked by the transac-tion and specifies temporal data constraints, i.e., only fresh data are allowedto be viewed. Otherwise, this constraint is relaxed.

2. AccessSet : it contains all objects already accessed by a transaction. Ac-cessSet is extended to specify temporal access policy, e.g., a transaction mustbe temporally correct or relaxed: absolute consistency and/or relative con-sistency and/or timely commit.

3. Conflict User/Update Set: it contains objects that users transactionwants access which are already locked by update transactions and vice versa.

Fig 2 shows the structural relationship of elements used by a perceived freshnessof a user transaction with update transactions.

4 Formal Definition of RT-ETM

In this section, we propose a formal definition of real time extended transaction.The class diagram presented in Fig 3 show a meta-model of real-time transactionRT-ETM. It represents different concepts and their interrelationship previouslydefined. e.g.; The class Transaction is specialized in two classes “UpdateTransac-tion” and “UserTransaction”. A UserTransaction can be composed by anotherUserTransaction named sub-transaction. To describe that the sub-transactioncan leave the scope of the upper transaction, we use an aggregation between up-per and sub transaction and not by a relation of composition. The specializationof RT-ETM allows the description of different transaction model and the defi-nition of new transaction model. Based in some rules in [18] [19], we present aFormal definition of RT-ETM using a Z language. Due to space, we show formaldefinition of a subset of class, relation and operation.[VALUE, TYPE SET, PRIORITY, PERIODICITY, DURATION,STATE TRANS, TYPE OPERATION, TYPE TRANS, FRESHNESS TYPE,STATE T DATA]

Fig. 3. Effects of user and update transaction on temporal and non temporal data

Example of methods

5 Conclusion

In this paper, we have presented the components of ACTA and then we haveproposed many extensions to facilitate: (i) the formal description of properties oftransactions in real-time databases, reasoning about the transaction interactionsand effects on objects. To this purpose, we have added many new dependencies tocapture more interactions between transactions in real-time environment and wehave introduce many concepts such perceived freshness, conflictSetUser/Updateto formalize and control the effect of user transactions on data (ii) the formaldescription of properties of temporal data. For this, we have defined many newconcepts to permit a finer control of real-time data items. We have presented ameta-model of real-time extended transaction model and we have showed a partof its description using a Z language.

References

1. Chrysanthis, P.K., Ramamritham, K.: Synthesis of Extended transaction ModelsUsing ACTA. ACM Transactions , Database Syst., Vol. 19, n◦.3, pages 450- 490(1994).

2. Xiong, M., Ramamirthan, K.: Towards the Specification and Analysis of Trans-actions in Real-Time Active Databases. RTBD’97, Burlington Vermont, USA, p327-348 (1997).

3. Schwarz, K., Turker, C., Saake, G.: Analyzing and Formalizing Dependencies inGeneralized Transaction Structures. In proc. of Int. workshop on Issues and Appli-cations of database technology, July 6-9, 1998, Berlin, Germany (1998).

4. Schwarz, K., Turker, C., Saake, G.: Transitive Dependencies in Transaction Clo-sures. Database Engineering and Applications Symposium, July 8-10, Cardiff,Wales, UK (1998).

5. Schwarz, K., Turker, C., Saake, G.: Extending Transaction Closures by N-ary Ter-mination Dependencies. Symposium on Advances in Databases and InformationSystem (Adibis’98), Semptember 8-11, Poznan, Poland, (1998).

6. Abdouli, M.: Study of Extended Transaction Model Adaptation to Real-timeDBMS. PhD Thesis, Le Havre university, France, (2006) (in French).

7. Kaddes, M., Abdouli, M.; Bouaziz R.: Adding New Dependencies to Acta Frame-work. Proceedings of 22nd European Simulation and Modelling (ESM’2008), LeHavre, France, 27-29, October (2008).

8. Haubert, J., Sadeg, B., Amanton, L.: (m-k) firm real-time distributed transactions.Proc. of the 16th WIP Euromicro Conference on Real-Time Systems (ECRTS),(2004).

9. Hamdaoui M., Ramanathan P. A Dynamic Priority Assignment Technique forStreams with (m,k)-Firm Deadlines. IEEE Transactions on Computers, 44(4):pp1325–1337, (1995).

10. Koren, G., Shasha, D. Skip-over: Algorithms and complexity for overloaded systemthat allows skips. In Real-Time System Symposium, pp 110–117, (1995).

11. Bouazizi, E., Duvallet, E., Sadeg, E.: Multi-Versions Data for Improvement ofQoS in RTDBS. Proceedings of 11th IEEE International Conference on Real-Timeand Embedded Computing Systems and Applications (IEEE RTCSA’2005), HongKong, China, pp 293-296, August 17-19, (2005).

12. Amirijoo, M., Hansson, J., Son, S. H.: Specification and Management of QoS inReal-Time Databases Supporting Imprecise Computations. Transactions on com-puters, vol. 55, no. 3, March, (2006).

13. Amirijoo, M., Hansson, J., Son, S. H.: Specification and Management of QoS inImprecise Real-Time Databases. ECRTS, pp.63, 15th Euromicro Conference onReal-Time Systems (ECRTS’03), (2003).

14. Purimetla, B., Sivasankaran, R.M, Ramamaritham, K., Stankovic J.A.: Real-timedatabases: issues and applications. Principles of RTS, ed. Printice Hill, (1994).

15. Kang, K., Son, S. H., Stankovic, J.A., Abdelzaher, T.F.: A QoS-Sensitive Approachfor Timeliness and Freshness Guarantees In Real-Time Databases. In the 14thEuromicro Conference on Real-Time Systems, (2002).

16. Kao, B., Lam, K., Adelberg, B., Cheng, R., Lee,T.: Maintaining Temporal Con-sistency of Discrete Objects in Soft Real-Time Database Systems. IEEE Trans.Comput., Volume 52, pp 373-389, (2003).

17. Xiong, M., Ramamritham, K.: On earliest deadline first scheduling for temporalconsistency maintenance. Real-Time Systems 40(2): 208-237 (2008).

18. Dupuy-Chessa. S., Bousquet, L.D.: Validation of UML Models Thanks to Zand Lustre. international symposium of formal methods Europe: FME 2001,Berlin, vol. 2021, pp. 242-258,(2001).

19. Ali. M.: Verification Et Validation Formelles de Modeles UML: Approches et outilsEditions universitaires europeennes, ISBN-10: 6131551359, December (2010).