CMSC 838Y Paper Reviews

Skip down to paper 0: Algis Rudys and Dan S. Wallach. Transactional rollback for language-based systems. In Proceedings of theInternational Conference on Dependable Systems and Networks (DSN-2002), June 2002. [ .html


Reviews for paper 0

Review from Piyush Bhagat <piyushb@glue.umd.edu> at Mon Mar 10 12:54:19 EST 2003:

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.       

Review from prashant lamba<plamba@wam.umd.edu> at Tue Mar 11 00:17:29 EST 2003:

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.

Review from Nathaniel Waisbrot <waisbrot@cs> at Tue Mar 11 10:25:56 EST 2003:

	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.

Review from Polyvios Pratikakis <polyvios@cs> at Tue Mar 11 11:19:39 EST 2003:

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.

Review from Yuan Yuan at Tue Mar 11 12:00:02 EST 2003:

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.

Review from Jeff Odom <jodom@cs.umd.edu> at Tue Mar 11 12:09:33 EST 2003:

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)?

Review from Bryan Payne <bdpayne@cs> at Wed Mar 12 21:32:34 EST 2003:

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.


Review from Mujtaba Ali <mujtaba@bitsmart.com> at Thu Mar 13 12:33:25 EST 2003:

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


mwh@cs.umd.edu

Web Accessibility