The history of TPPT®
TPPT has been developed for over 3 years. The
latest version v2.0 is the closure to the MS Projects of several people under the tutorship of
Prof. Arthur Bernstein: Helen Yi Ren and Sue Jie built the first version of TPPT
in 1999 in which the multi-user and single-user modes were run separately. Yang
Wang and Yan Zhang later contributed to some improvement in the Synchronization
part of TPPT (single-user mode). From Fall 2000 through 2001, TPPT underwent
several transformations by Jiang Yin which includes: the combination of
multi-user mode and single-user mode (v1.2); the separate tabulation of response
times for different scenarios in the execution of a transaction (v1.3); the
addition of a new interface which allows user to query into database after each
successful experiment (v1.4). For more information on the modifications to the
original tool, please read on. From 2002 to 2003, tool has been developed
and improved by Jodie Wu. For the feature of latest version v.2.0, please refer
to "New Feature".
v1.2 from v1.1:
- Combined multi-user mode with single-user
mode, a .txt file named "serverNames.txt" which contains
URL's for
different servers is expected to exist in the same directory as the class files
for running TPPT. In the absence of such file, TPPT will start running in
single-user mode and inform the user through a pop-up window.
- Expanded the functionality of "save
experiment setting" to cover all user input except for isolation level and
maxRowPerPage.
v1.3 from v1.2:
- The response time for each transaction is collected categorically by the outcome of each transaction. The execution of
a transaction can be in one of the four following cases:
- success: the transaction ran to completion,
no SQL or java exception occurred.
- logic failure: the transaction which usually
consists of several SQL statements, however it quit prematurely because the
result from some SQL statement(s) doesn't warrant the continuation of the
rest of the transaction.
- deadlocked: if transactions requiring access
to the same system resources are executed at the same time, they might
deadlock each other, it is then Sybase's choice to allow only one of them to
go through and abort all other transactions. The aborted transactions will
then be re-run twice, at which time they, if still haven't gone through,
will be aborted.
- exception: needless to say, if this happens,
the current experiment should be aborted.
- Use the drop-down list to
allow user to choose from different Sybase server.
v1.4 from v1.3:
- Save experiment now stores all information about an experiment, however,
it's the user's responsibility to keep track of changes made into user input
files, e.g., prototype file, scripts, etc.
- Prototype file now can be loaded during run-time.
- A new interface was introduced to allow user query into database after at
least one successful experiment, if the query runs without problem, the
results will be displayed and saved should user wish so.
- Each script will be run once and only once, instead of being looped.
- Synchronization in single-mode now employs stored procedure to assure
exclusiveness while one user is running experiment, eliminating a possible
bug in earlier versions.
Back
to Help Contents