The paper is about a methodology called transactional roll back applied to language-based systems. The basic use of the methodology is to save run time systems from the after effects of malicious or buggy codelets, which can cause abrupt termination of any other codelet leading the system to an inconsistent state from where it cannot recover. The basic principle underlying the methodology is If each instance of a codelet is run into its own transaction and due to some malicious codelet the running codelet is abruptly terminated then the transaction is aborted and all the changes made by the codelet are rolled back preventing the system from reaching an inconsistent state. If in the above case the codelet is restarted its state is initialized from scratch, as its execution state is not saved. Only the persistent state of the codelet is saved. The paper says that the two main data conflicts that complicate the design of the methodology are write after write and read after write. Constraining the order of operations in the transactions can prevent these. The paper says that the methodology can be implemented in 3 ways below, inside and above runtime system. Out of these I feel that above the runtime system approach is optimum as it solves several purposes like portability, security etc. The paper goes into the details of roll back explaining locking and backup maintenance. The paper then implements the methodology with java and explains the changes needed in the java code to support transactional roll back. The paper also deals with the performance issue and finds that the methodology has got a large overhead but at the same time It says that the methodology can be optimized.
This paper might be considered as extension work to the termination in the language based system.It highlights the need of the roll back to a safe state.So this paper gives an solution and implementation of this system.This is based on the simple mechanism of keeping the records of changes made by the codelet,taking in care of read-after-write conflict and write-after-write conflict.Architectural implementation is same as any language persistence.We can impelment this to run above run time system,inside run-time system or above the run time .Paper presents the details of all the implemnetation and sugesst that for portability of system we should chose to implement transactional rollback above the language run time using code - to - code transformation.In the next section the author explains the implementation of the roll back systemThe performance of the system can be improved by making changes to the run time system to aloow to annotate arrys with the direct references to thiere backup information. It also explains how to handle constructs and native methods in java. In the last section paper presents the performance of the system . In short this paper coninces the reader for the use transation roll back to a safe state.
As an extension to the "Termination in Language-based Systems" paper, this paper proposes that the codelets which might be terminated should make their changes in a transaction-based environment. This solves the problem of a terminated codelet leaving the process inconsistent, because terminating a codelet also reverts all the changes it's made. As before, the overhead for this is very large, here because they must make copies of everything they intend to modify, and mutex-lock each transaction. I was surprised at how little it appeared to cost them to modify the byte-code on the fly, though. I was under the impression that there are OO databases which have already been designed and which should be able to handle their transactions. I'd like to know why they decided to design their own, rather than just adapting an existing transaction system.
When data are shared between many untrusted codelets in a JVM, some of which might be terminated during the manipulation of such data, there is a risk of the system ending in an incosistent state. This paper applies database ideas about transactional rollback to bring any shared data into a consistent state, in the event of a codelet terminating after having brought the data in an inconsistent state. Code-to-Code re-writing is used to implement this system. In particular, a lock mechanism is inserted into the java bytecode of the original codelet, that ensures that "transactions", or executions of untrusted codelets can be rolled back in the case of abnormal termination. A "backup" of the data is taken at specific points and is restored or thrown away after the codelet ends. The transaction-id is followed through the execution of all threads, and by using locking, it is ensured that the roll-back will be correct. This paper presents the solution to the problem following the codelet termination mechanism by the same author.
To solve the inconsistent state problem caused by terminating codelets anywhere, this paper use the concept of transaction in database area to roll-base the system to its state (memory) before the execution of the codelets. Each codelet is run as a transaction and changes it makes will be track for rolling back if the codelet is terminated. By consideration of portability, transactional rollback above language runtime system is chosen here and class loader is the place to do the java bytecode modification. The way code-to-code transformation for roll back is duplicating each subroutine of codelet and parameters. The parameters represent the transaction, any application are performed on the duplicated subroutine. If the transaction commits, the backup of that transaction will be aborted, otherwise, the backup will be restored to recover the initial status of system. The idea based on transaction to roll back system is novel, but the performance shows that system is not yet suitable for use in practice. Optimizations need to deploy to improve the performance.
Following on their earlier paper, Rudys and Wallach consider data integrity when threads (codelets) are terminated. The novel idea they propose is to automatically extend objects to include a unique lock/object, and accesses to objects with a transaction (analogous to a database transaction). When an object is to be modified, that object's lock is acquired by the transaction, which makes a shallow copy of the object and recursively locks and copies any contained objects. If the codelet is abnormally terminated, the transaction is rolled back by replacing the values of all locked variables with their backups. Two questions remain after reading this paper. First is the issue of starting and committing transactions, which according to the authors would be performed by the system that hosts the codelets. How automated can these functions be? Secondly is the question of who performs the restore of the variables? Presumably this is done by the host system, but how (i.e. with what interface)?
I felt that the use of transactions fit this problem rather naturally. Specifically, the problem here is to enable the run-time system to stay in a consistent state, even if part of it terminates prematurely. By using transactions, one can obtain all of the benefits that transactions give to database systems. These benefits include data integrity and consistency, which is what was desired here. Interestingly, this system performed horribly. I say that this is interesting because databases can now exhibit amazing performance. While it is clear that the system described in this paper is not as optimized as Oracle, this does suggest an area to research in order to improve the speed issue. I feel that with further work, this issue could be addressed rather effectively.
This paper was intended as a sequel to the authors' previous paper entitled "Termination in Language-based Systems". Unlike the previous paper, however, this time around the authors forego formalization - which is probably a good decision considering the horrible theoretical explanation presented in the the previous paper. The authors propose a system such that, without any assistance from the user, a codelet can be transformed at load time to support transactional rollback. I am still not wholly convinced that codelets not specifically designed to operate in a transactional manner are well suited for this system. As the benchmarks show, certain types of operations produce catastrophic results in terms of performance. The developer must be aware of these limitation to produce a codelet that will function well in the proposed system. Before reading the paper, I envisioned a transactional approach being useful in an embedded setting, but the performance and code size drawbacks of the presented system are not intended for such an environment. By far the most disappointing aspect of the system is the possible _introduction_ and subsequent handling of deadlocks. This system introduces deadlocks and then, as a result, is forced to resolve those deadlocks by aborting transactions. I am uncertain how one would go about debugging in such a system. The authors are honest with regard to the sever performance penalties imposed by their system, specifically with array use. Also, the authors address I/O, but admit that, in the general case, support for I/O remains unresolved. Later, after presenting benchmarks of the system, the authors state, "Clearly, these numbers indicate our system is not yet suitable for deployment in practice." This wasn't surprising, but it was nice to have someone come out and explicitly admit that their system is purely a research effort. As always, I am constantly looking for recurring themes (or "trends") among the papers we are reviewing this semester. This paper highlighted two additional trends: 1. A considerable amount of language research is focused around introducing abstractions traditionally associated with non-language environments and apply these abstraction to language systems. For example, J-Kernel was concerned with implementing a process-like abstraction and this paper is concerned with implementing database-like abstractions (ACID transactions via two-phase commit.) 2. In my opinion, research papers are becoming overly concerned with implementation details and less with correctness. For example, this paper dedicated a whole section to Java native methods. At this point in the authors' research, addressing Java native methods is not important when other more serious issues, such as deadlocking, demand attention.
Generated: Thu Mar 6 15:39:24 EST 2003 by mwh