Design, development and implementation of a software system to automatically identify if a given history or a schedule is (a)serializable or (b)recoverable or (c)both.

Project description:

Execution of concurrent transactions must be serializable or recoverable or both to preserve database consistency. This is achieved through analyzing a given history using serializable and recoverability rules.

Requirements:

Generation of a history H: You should write a system to generate history randomly. This system will accept transaction size (number of data items) and the number of transactions

Transaction size: Max = 4 data items.

H size: Max 4 transactions.

Operations to be included in a history: read, write, and a combination of abort (a) and commit (c).

Project description:

Your system will generate a history randomly H and input it to the analyzer.

The analyzer will analyze the history and generate the correct output.

Output format:

For each result, it must give the reason. For example, if H is serializable then it must say all conflicting operations of Ti comes before all conflicting operations of Tj where Ti -> Tj and there is no cycle.

You should draw graphs to show how things change. For example, you could consider showing a graph of average transaction size vs. number of positive or negative results. You are in charge so you decide how to best present your results.

Resource needs:

A random history generator and a simulated database. In the history generator, you may consider inputting the size of a transaction (number of data items), number of transactions for the history and number of reads, writes, commits (c) and aborts (a).