|
This paper presents new and implementation-independent specifications of the ANSI-SQL isolation levels. It first discusses the restrictiveness of preventative approach (locking), since it rules out optimistic and multi-version implementations, and prevents conflicting operations from executing concurrently. By contrast, this paper's definitions allow different isolation guarantees for committed and running transactions. The paper describes the database model (consists of objects to be read or written by transactions with multiple versions), transaction history definition (how to record histories), how predicates are handled, what are different types of possible read/write conflicts, and what are different isolation levels. The defined isolations levels include: - PL-1, Ti's writes completely isolated from the writes of other transactions - PL-2, Ti has only read updates of transactions that have committed by time Ti commits - PL-2.99, Ti completely isolated from other transactions with respect to data items - PL-3, Ti completely isolated from other transactions The main advantage of the paper's result is that the definitions are implementation dependent, which gives users more space to do their own implementations and perform concurrency control. This level of flexibility is highly desired. |
|
Current ANSI standard isolation level definitions are ambiguous and constrained to locking implementations. This paper aims at proposing a new and precise definition of ANSI-SQL isolation levels. It’s important to have this new standard because the old standard is not implementation-independent with multiple different definitions in different situations. This paper first reviewed previous ANSI isolation level standard. Then it shows the fact that preventative approach used previously is restrictive because it didn’t consider optimistic and multi-version implementations. After that the paper presents the database model, transaction histories and serialization graphs of their design. At last the paper shows the new specified isolation levels. The new specification allows more concurrency mechanisms like locking, optimistic and multi-version mechanisms while the old standard only allow pessimistic locking method. The new definition is more permissive because it covers weaker isolation levels which is widely used to achieve better performance. Additional isolation levels used in industry like Cursor Stability and Oracle’s Snapshot Isolation and Read Consistency which is considered the weakest level are also in the scope of the new standard. The paper is not presenting the details of additional levels like PL-2+ used for the commercial products like the Cursor Stability, which is a little drawback of this paper. |
|
The paper presented new precise specifications for ANSI- SQL isolation levels, which are both correct and implementation-independent. The current isolation levels defined in ANSI standard are ambiguous, and the revised versions are too constrained to include implementation-independent implementations. Therefore, this paper presented new implementation-independent specifications that correct the problems with the existing definitions. Their proposal contains database model, transaction histories and serialization graphs. The database model is a multi-version model with unborn, visible and dead object versions. This model assumes object versions exist forever in the committed state to simplify the handling of inserts and deletes. The transaction history consists of a partial order of events which reflects the operations of those transactions and a version order, which is a total order on committed versions of each object. This model handles predicates by a predicate-based read followed by write operations on tuples which match the specific predicate. Finally, the serialization graphs are specified by read dependencies, anti-dependencies and write dependencies. Then this paper defined isolation level PL-1, PL-2, PL-3, PL-2.99 and mixing of isolation levels using the concepts previously mentioned. The main contributions of this paper are 1)It specifies the existing ANSI isolation levels in an implementation-independent manner with definitions which are both correct and complete for serializability; in particular, they provide conflict- serializability. 2)It also can handle predicates correctly in a flexible manner. 3)It can be used to define addition levels including commercial levels and new levels. This paper applied mathematical approaches to defining isolation levels, which is precise and therefore convincing. Besides, this paper not only defined the common isolation levels, but also gave a way to specify the behavior of systems that allow mixing of levels, which means the proposed specifications are flexible. The main disadvantage of the paper is it cared too much about technical precision when giving definitions, which makes it harder for readers to understand. It would be better if this paper could explain the definition by using terms which are less technical or by giving examples. |
|
Problem & Motivation: Commercial databases can support different isolation levels to allow programmers to trade off consistency for a potential gain in performance. However, the traditional definitions of the isolation level are ambiguous. And some previous works are not implementation-independent. Therefore, the author of the paper proposes a generalized isolation level definitions which consist of 4 levels. Contributions: The author proposes the generalized isolation level definitions which are precise and implementation-independent (locking, optimism, serialization). It adopts the dependency graphs and abstracts the database model to achieve generalization. Drawback: From my perspective, the main drawback is that this paper involves too many unknown items, especially for the beginner. One example is the term "optimism" where I never know before, yet the author treat is a well-known thing (well, maybe it is). |
|
Isolation levels are used to provide the user the ability to trade off consistency guarantees, which often require locking, in exchange for improved performance. While this idea had been around for some time, precise implementation-independent specifications were lacking. This paper attempts to rectify that problem by introducing implementation-dependent specifications that also fix some of the issues inherent in the definitions in use at the time. In addition, the specifications can handle predicate operations correctly at all levels. The authors start by detailing prior work, which tended towards a pessimistic (i.e. locking) approach, which they show to be overly restrictive by ruling out optimistic and multi-version implementations. Following this section, the authors explain the database model, transaction history, serialization graphs, and how predicates are incorporated into the model. This is followed by a discussion on their specifications on the ANSI isolation models. There are 4 levels, PL-1, PL-2, PL-2.99, and PL-3 mentioned, and in general, each level progressively allows fewer types of phenomena. This has the effect of creating greater guarantees on the isolation (and therefore consistency) for a given transaction to be committed. One key difference is that the restrictions are only on committing transactions, rather than on reading and other types of tasks being done by a transaction. The key strength of this paper is that it provides a systematic definition for the isolation levels which conform to the ANSI-SQL standard. The fact that it is implementation independent makes it much easier for widespread industry adoption and indeed was a primary goal of the paper. At the same time, users have greater freedom in terms of what guarantees they would like or would rather forgo. Each isolation level is described in great detail, e.g. the allowed and prohibited phenomena. This paper proved to be rather dense and will probably require quite a few rereads in order to grasp it more fully, so I cannot comment on the merits and weaknesses of the proposed specifications, or if it managed to meet the original claims set by the authors of being a flexible implementation independent scheme. |
|
This paper aims to define the ANSI-SQL standard isolation levels to allow different concurrency techniques like locking, optimistic techniques, and multi-versioning mechanisms. This is important because in prior work, definitions seemed to restate the lock technique definition and therefore disqualified other valid concurrency implementations. This was a flawed and incomplete definition that this paper wished to improve upon. The author outlines a few valid implementations of concurrency techniques that are improperly excluded from the current isolation level definition. The paper then defines the database model and transaction histories in order to lead into the specification that is the paper’s contribution. It covers how query predicates are handled in the model and finally, before defining the isolation levels, the paper describes a few challenges with concurrency management. Then it introduces the specification for the isolation levels, which are defined in terms of what is disallowed. It deals with varying levels of transactions’ ability to read or write uncommitted or inconsistent data. I like how the paper explicitly outlines its contributions, this helped give me an endpoint so I could focus on how they got to those results. They also break down which sections will expand on the content mentioned in that first section. I liked how the paper defined terms and presented its database model before presenting it’s contribution, so that I as a reader am on the same page. I would say I didn’t like how the paper did not indicate any assumptions it had of the reader’s prior knowledge or familiarity with the subject and terminology. Perhaps I started reading with less knowledge than I should have, but it took me a few paragraphs after the abstract to realize what the paper’s purpose was. I did not know some of the terminology but I eventually found the context. It would have been nice, however, if the author spelled out some of the acronyms or defined the terms like the ANSI-SQL standard and gave some context for the isolation levels mentioned in the title. Some of the terms were defined later in the paper but I feel as though I lost some earlier understanding because it was introduced so late, on a first read. |
|
This paper overall proposed new, portable, and precise definitions of ANSI-SQL isolation levels which resolve the ambiguous definitions of previous ones. The most important concept of new proposed definition is correct and implementation-independent. The main contribution of this paper: 1)specify the existing ANSI isolation levels in implementation-independent manner 2)handles predicates correctly in flexible manner. This paper shows that the presentation approach is overly restrictive by ruling out optimistic and multi-version implementations. And states that the problem of the preventative approach is that the phenomena are expressed in terms of single-object histories but with the properties of interest being often multi-object constraints. Therefore, the proposed approach uses specifications that capture constraints on multiple objects directly. The paper gives a comprehensive introduction of the proposed database model, transaction histories and serialization graphs. 1) the database model is a multi-version model. The most important idea is each object has one or more versions so that a transactions may read versions created by committed, uncommitted and aborted transactions. A new version of object can be created when it is being written and also, the modification of an object can be execute multiple times by the transaction. 2)the transaction histories consist of a partial order of events who reflects the operations of transactions and a version order. 3) predicates: the paper introduces predicate-based reads and modifications(a predicate-based read followed by write operations on tuples that match that predicate). The predicates are assumed to be used with relations in relational database system. And given the definition of Vset(P) 4) defined direct conflict that capture conflicts of two different committed transaction of same object which is used to specify serialization graphs. The proposed definitions for the existing ANSI isolation level: 1)PL1, allows dirty reads, disallow write cycles, be able to visit uncommitted changes. 2)PL2, allows non-repeatable reads, disallow dirty reads and write cycles. 3)PL2.99, allow phantom reads, provide serializability for individual data items, but not queries 4)PL3, completely isolated. The drawbacks from my point of view, I would hope author analyze the performance under of standard implementation of its proposed definition. |
|
Transaction isolation is a fundamental component of database system design. This paper gives a better definition of ANS-SQL isolation levels. The author point out that in the old ANSI SQL standard only uses locking as the supported concurrency method, and the method that is proposed by author will be general and support optimistic and multi-version. In the content of this paper, the author defined phenomena named G0, G1, G2, which are general enough to allow locking and optimistic implementation. And the new levels are labeled as PL levels. G0 represent a write cycle, which means that two transactions are writing the same data at the same time. It should be prevented since one transaction’s write should not be overwritten. G1 mainly captures the essence of no-dirty-reads, which means that a transactions should not read from uncommitted or aborted transaction. G2 stands for phantom read, which means that the transaction get different result by the same operation. The author then define portable isolation level based on the phenomena. PL-1 provide serializable write by disallow G0 which is write cycle. PL-2 is achieved by disallowing G1, which disclude Aborted Reads, Intermediate Reads and Circular Information Flow. Isolation Level PL-2.99 is also named as Repeatable Read, it provides less than full serializability. Anti-dependency cycles due to predicates can occur at this level. PL-3 prohibits Anti-dependency cycles. The main contribution of this paper is that it provides a more precise and general isolation level that is not dependent to implementation. The paper also point out the limitation of existing isolation levels is that it only allow locking but not optimistic and multi version. The paper also provide the definition of phenomena that is independent from implementation. |
|
The paper gives new definitions for SQL isolation levels, as the defined ANSI SQL-92 definitions have been shown to be ambiguous. Previous work had attempted to do this, but had been dependent on implementation, disallowing multi-version and optimistic concurrency schemes. Those schemes are useful in some implementations, and therefore having a specification that takes them into account is critical. The specification also covers predicates, which weren’t correctly handled in previous work. The authors define three types of direct conflicts: read dependencies (wr), anti-dependencies (rw), and write dependencies (ww). These are then combined to create the direct serialization graph (DSG), which is a useful way of visualizing the dependencies. Finally, they define generalized phenomena, and “portable levels.” The generalized phenomena allow histories that would not be allowed by the phenomena defined in previous work. The portable isolation levels are defined by disallowing certain general phenomena. The paper does a good job clearly defining their isolation levels, and how they relate to the generalized phenomena. The most effective tools used to explain this, in my opinion, are the DSG and the table provided on page 11. One other thing that I appreciated was the more concrete SQL statements provided in the section on predicates. I think that more of this type of explanation would have been useful. In the end, the main contribution is that the paper presents specifications that are able to work with different locking implementations - this is clearly critical, as the next paper we read indeed discussed implementing the serializable isolation level with multiversion concurrency control. The paper gives a fair amount of notation in the first few pages without fully explaining it - I was impressed with the descriptions of notation defined for this paper, but not what was used in the previous work section. The process is described, but not the notation itself. I assume that this is not novel notation - it was probably used in one of the papers being cited - but I do think that some background on the notation itself would still be helpful for the reader. |
|
This paper purposed a new isolation level specifications for the ANSI-SQL. The motivation for this new specification is that the ANSI-SQL standard is supposed to be implementation-independent and precise, but the existing standard does not meet these two requirements. For example, an isolation level is defined by implicitly assuming lock scheme is used and therefore, excludes the optimistic and multi-version implementation mechanisms. New specification purposed is not only implementation-independent, correct and complete, but can also handle predicates correctly. To explain the new specification, the authors first described the database model, transaction histories and serialization graphs (DSG). The key idea for database model is that each row of a table (a tuple) can have one or more versions and there are two special versions called unborn and dead to facilitate the insert and delete operation. The history over a set of transactions consists of a partial order of events(read, write, commit, etc.) and a version order for each tuple. Then new definitions including predicate-based read, read/write/anti-dependencies were given and the serialization graph is further defined based on the dependencies. Based on the model and serialization graph, a new specification for a certain level is defined in terms of phenomena that must be avoided. For example the new PL-1 isolation level is defined by disallowing DSG from containing directed cycle consisting entirely of write-dependency edges. The isolation levels defined were in general weaker than the old definitions so that implementations other than locking can be used. It will be better if the paper can also give the specification for other weaker isolation levels that are commonly used. Some real examples of how other implementation methods can utilize the new specification will also be great. |
|
In the paper "Generalized Isolation Level Definitions", Atul Adya, Barbara Liskov, and Patrick O’Neil discuss new and precise definitions of ANSI-SQL isolation levels. They make strong claims such as correctness of their definitions and implementation independence. Furthermore, their specifications allow for concurrency control techniques such as locking, optimistic techniques, and other multi version mechanisms. The purpose for introducing such enhancements were to replace the former ambiguities and bad histories in ANSI/ISO SQL-92 and suggest improvements to allow for implementation independence. They attempt to handle predicates in a flexible manner and prove that their definitions are much "more correct" definitions from previous works. They tackle this because they feel that database vendors and programmers take advantage of levels below serializability in order to gain better performance. It stands to reason that giving them more tools at their disposal such as locking can enable them to be more innovative with their data. Previous work took on a preventative approach where the definitions only allowed histories that would occur in a system using long/short reads and writes with item and predicate locks. Locking completely prevents situations such as concurrent writes to the same object from occurring in the first place - but Adya sees this as restrictive. This prevents conflicting operations from executing concurrently which consequently disallow optimistic and multi-version mechanisms. Since the phenomena was represented by single object histories, it needs to restrict what it does with individual objects much more strictly. Thus, since there is an interest in optimistic and multi-version mechanisms and these give weak guarantees to transactions and strong guarantees to serializability, Adya decides guarantees for committed transactions is of value. Thus, in this new data model, we have transaction histories, predicates, a way to model conflicts and serialization graphs, as well as various isolation levels. The paper did a great job of explaining the faults of previous approaches and clearly defining their interests. I felt that the graphs also contributed greatly to the understanding of the example transactions they used in order to explain direct serialization for different isolation levels. However, the paper did have some drawbacks as well. I never clearly understood their motive for proposing a new method. As discussed in class, I thought that the process to change SQL standards was a menial and tedious task. Will people even adopt this new standard if the old one is not facing any major problems? Furthermore, I would have liked to see more discussion on actual implementations on larger transactions. I only see claims that say that industry adoption is supported, but lack hard evidence for this. |
|
This paper summarizes several isolation levels that a DBMS can work in. Each of these levels gives certain guarantees on what transactions can and can’t do. These levels are notably slightly less restrictive than previous levels, while still providing useful guarantees. Each isolation level prevents certain “phenomena”, which are certain actions that may be undesirable. Older isolation levels defined phenomena on individual objects (each object being a single row of a single table), but most interesting phenomena involves interactions between multiple objects. In order to classify these phenomena, there are three types of conflicts between transactions: Read dependency: One transaction reads the change of another transaction. Write dependency: One transaction writes over the change of another transaction. Anti dependency: One transaction overwrites what another transaction has read. Using these, any history of transactions can be represented as a directed serialization graph, where each node is a committed transaction and each direct edge represents a conflict between transactions. Then, the isolation levels are: PL1: No cycles of write dependency edges PL2: No cycles composed of mixtures of read and write dependency edges PL3: No cycles of any kind of conflicts PL2.99: Like PL3, except a cycle is allowed if it has anti dependencies based on predicates, not items. Each transaction in a DBMS can be run at its own isolation level, so levels don’t have to be the same across the entire DBMS. This paper is able to provide effective definitions of its isolation levels. Notably, these isolation levels are very similar to previously existing levels, which allows for easy adoption. However, they are slightly looser, as they’re built off of analysis of the DSG, rather than analysis of single objects. This allows the levels to better correspond to issues that a DBMS that may be considered more important. This paper, however, was very difficult to read at times, mostly due to the use of symbolic language that didn’t seem to add much in terms of comprehensibility. Almost every term (such as the isolation levels and transaction conflicts) is defined by symbols, when the written English definition would generally be clearer and easier to read. The symbols may be more precise, but they bring a level of precision that is usually unnecessary. |
|
The paper mainly focuses on developing new isolation levels for concurrency control scenarios in ANSI-SQL standards. It’s crucial as we have to maintain the atomicity of transactions precisely. The paper developed in a theoretical way by introducing traditional isolation levels, conceptions, defining new conceptions and introducing new isolation levels. The traditional isolation levels are based on proscribing four phenomena P0,P1,P2,P3 in a different way. In order to improve performance and meet ANSI-SQL standards, the author develop modified phenomena G0, G1a, G1b,G1c,G2 and G2-item, which are basis of new defined isolation levels. The paper moves on for developing isolation levels which is implementation-independent and allow a wide range of concurrency control techniques, including locking and optimism. Is it worth adapting these new rules remains doubtable, but the research on analysis of isolation levels is pretty helpful. The paper mainly focuses on developing new isolation levels for concurrency control scenarios in ANSI-SQL standards. It’s crucial as we have to maintain the atomicity of transactions precisely. The paper developed in a theoretical way by introducing traditional isolation levels, conceptions, defining new conceptions and introducing new isolation levels. The traditional isolation levels are based on proscribing four phenomena P0,P1,P2,P3 in a different way. In order to improve performance and meet ANSI-SQL standards, the author develop modified phenomena G0, G1a, G1b,G1c,G2 and G2-item, which are basis of new defined isolation levels. The paper moves on for developing isolation levels which is implementation-independent and allow a wide range of concurrency control techniques, including locking and optimism. Is it worth adapting these new rules remains doubtable, but the research on analysis of isolation levels is pretty helpful. |
|
This paper starts off by introducing the concept of isolation levels is to trade off consistency for potential better performance. The definition of isolation levels in this paper differ from previous studies. Previous definitions support only pessimistic implementations, however definitions in this paper support not only pessimistic but also optimistic and multi-version concurrency control schemes. Following introduction, author explains previous isolation levels of Read Uncommitted, Read Committed, Repeatable Read, and Serializable. Then, author states that the isolation levels are too restrictive and disallows all histories that would not occur in a locking scheme. There are several scenarios provided in this section to support the argument. After that, author explains some basic concepts and notations in database model, transaction history, predicate, and serialization graphs for readers to understand the new proposed definition of isolation levels in the following section. Author proposed the new isolation levels of PL-1, PL-2, PL-2.99, and PL-3, which are weaker than the previous levels to allow more transactions happen concurrently. Author also introduces the concept of mixing of isolation levels and definitions of mixing correct. What I like about this paper is that author have a lot of examples to both support his argument and explain his proposed definitions. However, I do not like the overall structure of the paper. The section that explains the basic notations and concepts is after the summary of previous studies. Therefore, I am quite confused when I read the summary of previous isolation levels. I had to revisit the section when I read this paper. |
|
“Generalized Isolation Level Definitions” by Atul Adya et al. presents new specifications for ANSI-SQL isolation levels: definitions that are clear, implementation-independent (therefore, supporting optimistic or other implementations that vendors think appropriate), and handle predicates correctly. The paper is motivated by a series of earlier proposals and work in isolation levels, which is provides an overview of: the first, which was not implementation-independent, the second, which was implementation-independent but had ambiguous or missing specifications of phenomena, and the third, which discovered issues with the second and proposed a preventative approach. Atul Adya et al. then show why this preventative approach is restrictive (that it does not support optimistics and multi-version implementations). Next they discuss their database model (a multi-version one), how they represent transaction histories, how predicates are handled, what read/write conflicts can occur, and the conflict/serializability graph that results. With this in mind, they present their generalized isolation specifications. The isolation levels are described as phenomena that must be avoided, or rules for when a transaction is allowed to commit. It was helpful that the paper provided enough background on the prior isolation level proposals so that reader outside of the field could understand the context. Relatedly, it was helpful that the paper explained disadvantages of the preventative approach. It also made sense that the authors presented the high-level database model they were considering, as it helped ground their description of isolation specification levels. |
|
This paper proposed generalized isolation level definitions. For DBMS, isolation level is an important configuration for users to choose to make a trade-off between consistency and performance. The paper argued that the ANSI standard isolation level definition didn't meet the goal of implementation-independent, which made the definitions to be ambiguous. This paper introduced the original isolation level definitions in detail, and use examples to show that this approach is overly restrictive since it rules out optimistic and multi-version implementations. Then, it introduced its database model, transaction histories, and serialization graphs. They used a multi-version model which incorporates predicate. They defined different types of read/write conflicts to specify serialization graphs. They finally gave their isolation level definitions, PL-1, Pl-2, PL-3, and PL-2.99. In a nutshell, this paper gave the full definition in a clear, rigorous way. It's a big contribution to the database community since the new definition allows a wide range of concurrency control techniques. And the implement-independent property is great for the industry. However, I wonder whether this work is widely accepted by the database community since it seems that the papers (published later) talking about isolation level still use the term "read committed", "serializability". E.g. "Serializable snapshot isolation in postgresql". |
|
In this paper, the authors purposed a new, precise and generalized definition of ANSI SQL isolation levels. Isolation levels are important concepts in modern DBMS, which allow programmers to make a tradeoff between consistency and performance. However, when the researchers were writing this paper, the isolation levels defined in ANSI are too ambiguous, the revised definitions are too constrained. Besides, although the standard is intended to be implementation independent, it lacks a precise definition that meets this goal. This problem is important because a good definition of isolation levels make the actual implementation of DBMS clearer and easier, this flexibility to programmers leads to good performance in some environments. In order to solve this problem, they presented new portable specifications which are both correct and implementation-independent. They provide a wide range of concurrency control including locking, optimistic techniques and multi-version mechanisms. Next, I will summarize the crux of this paper with my personal understanding. First of all, it introduces the traditional preventative approach including 4 locking isolation levels and corresponding proscribed phenomena and usage of different read-write locks. However, this approach is very restrictive since it rules out optimistic and multi-version implementations. Optimistic and multi-version mechanisms are less restrictive which allow many legal histories so that it is a good idea to incorporate such mechanisms into new isolation levels. Then, they gave a comprehensive introduction to their data model, transactions histories, predicates, conflicts and serialization graphs. In the data model, they discussed transactions in their model and the type of object versions: unborn, visible and dead. For transaction history, it consists of two parts: operations and version order. Some constraints are given which is required to be applied to the transaction history. For predicates, they first give a definition of version set and then talk about the use case of predicates in two scenarios: reads and modifications. Then, three kinds of conflicts are defined include write-depends, read-depends and anti-depends, based on that a direct serialization graph (DSG) arises which captures the transaction history. Based on previous definitions, they then discussed their new generalized isolation specifications with PL-1, PL-2, PL-2.99, and PL-3, they also introduced mixed serialization graph (MSG) and make a comparison between DSG and MSG. They did a good job in refining the ANSI SQL isolation levels, next I will summarize the technical contributions of their work. First of all, it solves the “disguised versions of locking” problem and enable optimistic and multi-version mechanisms, this allows a much flexible control of programmers to achieve better performance. It also specifies the existing ANSI isolation levels in an implementation-independent manner which is both correct and complete for scalability. Their definitions are given using a combination of constraints on transaction histories and graphs and can be used to define additional levels, which is quite innovative. I think to use a graph is a good idea, since through which people can easily understand the relationships among transactions. Besides, it also handles predicates correctly in a flexible manner, just as they said in their paper, their specifications handle multi-version systems, optimistic systems and also deal with predicates in a correct and flexible manner at all isolation levels. From my point of view, it’s a great paper, it stands on the view of programmers and focuses more on implementation independence. Besides, it also a good introduction of isolation levels that I am not familiar with previously. I think there can be some kind of drawbacks of this paper. First of all, as they said in their paper, their model only guarantee committed based transactions, they are taking running transactions into considerations. Besides, they purposed a lot of definition in their paper with a lot of texts, which is tedious to read and understand those concepts. It will be better if they can give more examples with the introduction of definitions. |
|
The paper introduces a new specification of isolation levels that are designed to be more implementation-independent than the then-current ANSI-isolation levels, while still remaining accurate. The two main phases of the paper are: 1) A discussion of the abstract database model the paper assumes for its new isolation levels. The main features of this are a system of objects that are assumed to always exist, but can exist in different states (unborn, alive, dead). Also, transactions/other events are kept track of by an important history log, as well as a directed graph called DSG which is complementary (but not a replacement for) the history log. 2) A new set of isolation levels, based on phenomenons, which are events that should be avoided at a given isolation level. Steps to avoid these phenomenons are how the isolation level is defined, and it is defined using the language of the history and DSG. The main strength of the paper is that it clearly outlines what the problems of the previous isolation level specifications are, and it seems to introduce a new system which addresses those issues (namely, allowing for non-pessimistic implementations while staying accurate). These goals were apparent and the paper never seemed to stray from them. The main weakness of the paper was that it was (in my opinion) fairly difficult to follow at times. In particular, I found the discussion on the details of the previous isolation level specifications to be quite confusing, and I had to take the author’s word for it at times about what conclusions I should be drawing. It’s possible that my background in this area is weaker than the authors’ intended audience, but I still felt that it could have explained certain sections better. |