| Who: | What: | When: |
| DK, KM | Have been reading stuff on two-phase commit, omniconnect, and dbi possibilities and trying to install postgres on antares. Haven't been able to install postgres as of today. | As of Sept. 29, 1998 |
| DK, KM | Discussed implementation of two-phase commit using two different instances of an Oracle database. Laid out a pseudo-code for the implementation. | Sept. 30, 1998 |
| DK | Created tables (indstudy_person in frog and indstudy_salary in tadpole) that we can use when implementing our two-phase commit test. | Oct. 4, 1998 |
| DK | Wrote a program using perl and DBI that implemented the two-phase commit transaction that we talked about above. Program is on chi under ~oracle7/ecdba/www/scripts/indstudy/. We need to get an account on chi with access to the database so that we can have all our programs there and Kennedy would be able to work on them too. | Oct. 5, 1998 |
| KM | Read the documentation in installing DBD-Pg. Tried to get it from ftp.orst.edu/pub/packages/CPAN/authors/id/MERGL/DBD-Pg-0.73.tar.gz Had problems with ftp site. Access Denied. Will try installation again. Messed around wth the sytax involved in creating databases. Messed around with Postgres. | Oct. 7, 1998 |
| DK |
Looked at Postgres SQL and created tables in Postgres instance
indstudy. Read more stuff on transactions, specifically two-phase-commit. | Oct. 12, 1998 |
| KM | Read a good chunk of Chapters 4 "Transaction Models", chapter 9 "Log Manager", and a bit of chapter 10 "Transaction Manager Concepts". Understood the underlying issues in the Transaction Manager and its implementation. Had problems trying to figure out how to put everything together into one larger picture with respect to our project. Discussed this with charlie and later with Dusko and Charlie in meeting. | Oct. 15, 1998 |
| KM | Thought of how to put together a script that would bring in the Transaction Manager, and resource managers, as well as utilizing the two-phase-commit protocol. Have a much better idea on how to implement them. Discussed with Charlie and Dusko based on Dusko's idea and model of the pseudo code he had. We have several bridges to cross such as getting DBI working on tsetse. I will do some work on that, and try and contact Chris as well as other system administrators to help tackle the problem. | Oct. 17, 1998 |
| DK | Thought on a way of calling up a script that handles the transactions in a way so that there can be n-number of transaction managers and n-number of resource managers under each transaction. I came up with a way to represent a string that will have all this information. Something like: T1:R1-DB-SQL;R2-DB-SQL;...;RN-DB-SQL.T2:R1-DB-SQL;...;RN-DB-SQL....TN:... where TN is the transaction manager (n being the number of transaction manager), RN is the resource manager (n being the number of the resource manager), DB is the specific database (or instance) the resource manager will be using, and SQL is the SQL to be executed against that database (or instance). | Oct.17, 1998 |
| DK | Talked to Charlie about issues behind transaction processing and Jim Gray's book. Decided that we need to look at logging by the transaction manager (and for that manner by the resource managers too). Read most of chapter 4 and 9, and the two-phase-commit part of Jim Gray's book. Have questions on logging and our implementation of it. | Oct. 20, 1998 |
| DK |
Wrote a script to test the use of DBI on postgres. Ran into problems with
DBI. Found out that I had used the wrong syntax, but even after using the
right syntax DBI didn't work. Error was that install_driver(Pg) failed
because a loadable object could not be located for module DBD::Pg in @INC.
Talked to Chris about this. Not yet resolved. Also, worked on pseudo code for implementing n-number of transactions with n-number of resource managers. Developed pseudo code without threads, but realised that we need to think about implementing transaction processing with threads (or processes?) so that more than one transaction and definetly more than one resource manager can be executed at the same time. | Oct.21, 1998 |
| KM | Worked some more in trying to understand the problem wityh DBI. Visited a good site, http://www.hermetica.com/technologia/perl/DBI/ hoping to learn more about the problem. As far as the problem with DBI goes, advise from Charlie is to either move the file to an appropriate directory that is in @INC or add /usr/local/lib/perl5/site_perl/DBD/ to @INC. Tried to point the @INC variable to a different one but this did not solve the problem. Will try to contact Jim and try to make some advancements by the next meeting. (S.O.S situation!) | Oct. 22, 1998 |
| KM | Attended system administartors meeting and discussed with Charlie, Josh, Chris, and Jim about the problem with DBI. We decided that Chris, Jim and I as well as other sysadmins would try and work on it more. Tried to run the test scripts which failed as usual. Worked some more on the problem with DBI. The problem reported is that :- install_driver(Pg) failed because a loadable object could not be located for module DBD::Pg in @INC. The problem lives on... | Oct. 26, 1998 |
| KM | Finally, the problem has been solved. Jim downloaded the newest versions of DBI and the DBD::Pg driver and installed them on tsetse. They're working now. I tested the scripts test2.pl and test_DBI.pl (postgres/indstudy) and made minimal changes for them to work. Hallelujah!! Finally off to the races. | Oct. 27, 1998 |
| DK | Wrote a paper on Database Transactions - Two-Phase Commit Protocol. | Oct. 26, 1998 |
| DK | Read on processes and interprocess communication. Got an idea of how to implement resource managers as processes (children) under the transaction manager. | Nov. 1, 1998 |
| KM | Wrote the Project Documentation (intro, overview and Functional Specification). | Nov. 2, 1998 |
| DK,KM | Wrote the Project Documentation part on Design Specification. | Nov. 3, 1998 |
| DK | Updated the webpage with the Project Document. Still need to put the paper online. | Nov. 5, 1998 |
| KM |
Wrote out the pseudocode and startegized on how to log in stuff into a log
file. One of the important parts in this process will be writing to disk
without buffering the information. That way, if a system crush happens,
everything will definitely be in memory. It is very crucial to the
recovery process.
Started writing some of the code for implementation. | Nov. 6 - Nov. 8, 1998 |
| DK | Worked on scripts for certain things like forking to achieve one parent to multiple children processes; interprocess communication using shared memory and semaphores; and client/server architecture, having in mind that our piece of softweare is going to be the server. Still need to figure out things about each of these pieces of code and really understand what's going on. There are a bunch of bugs I need to work on. | Nov.8 - Nov.11, 1998 |
| KM | Wrote pseudocode on the recovery process. Worked on a script to do simple reading from a file and using split in order to divide each line into small chunks to identify crucial messages in log file. | Nov.10 - Nov.12, 1998 |
| DK | Started incorporating the individual scripts that I worked on into one transaction server script. Putting everything together is harder than I thought it would be. Anyways, need to do a lot of work on that. Ken is going to be working on logging and recovery. | Nov. 22, 1998 |
| KM | Worked some more on the script for logging. I do not know how to write to disk directly without buffering the data first. Will read about it to get the syntax. | Nov. 25, 1998 |
| DK | Still working on the transaction server script. Finished the first part of it, i.e. the initial execution of the SQL scripts by the individual children of the parent transaction process. Have bunch of bugs that I need to figure out. | Dec. 1, 1998 |
| DK | Worked more on the transaction server script. It seems like it is a mess. I am trying to figure out where the script breaks. In the process, I think I messed up the connection to Postgres. I restarted the postmaster but I still get an error saying that the backend closed the channel and that there is a broken pipe. I am now getting frustrated. | Dec. 8, 1998 |
| KM | Started working on an annotated bibliography of the books that I have used throughout this semester for the independent study. | Dec. 10, 1998 |
| DK | I decided not to use shared memory communication and semaphores since, obviously, I did not learn enough to be able to use them and they kept crashing and using up tsetse's shared memory. I worked on another script dusko_server.pl which basically does the same but is limited to only one transaction at a time and resource managers are not run in parallel. Still, for some reason, things are going wrong. It seems like I cannot keep track of my information even though I store it in @trans_array. It seems like it never gets into @trans_array... and the modulo (%) operator confuses me by returning 5 when I do 19283736500 % 10. That is not right, right? Anyways, I am a bit confused right now and I don't seem to be able to think straight so I may come back to this later. | Dec.14-15, 1998 |
| KM |
Went through the scripts that dusko has been working on(dusko_server.pl,
log_server.pl, trans_mngr.pl) and made a copy of dusko_server.pl to
ken_server.pl and tried to incorporate the scripts that I have been
working on.
Logging
- the logging should be done by writing to disk without buffering. Still
trying to understand how to do this. I cannot find the commands. Charlie
suggested autoflush of which I cannot find in any of the Perl bibles.
Recovery - The recovery subroutine should be able to read the log file
backwards so that it can go up to the last thing that was committed and
then it will know where to begin the recovery process.
| Dec. 16 - Dec. 17, 1998 |
| DK | Last night I had a dream of an alternate way to do the rollback or commit with the rc handle, since it was not working before and I was getting frustrated with it. I thought of storing all the rc handles in a separate array that has nothing to do with the different resource managers (idea being that all of the rc handles need to perform either rollback or commit so it did not matter what resource manager they are connected to - as long as they are with the same transaction, which is taken care of since we are doing one transaction at a time now). However, it seems that the problem lies somewhere else. It seems as though I cannoct keep the rc handles in any array of any sort. Whenever I record the rc handles and then try to get back to them, I loose the actual handle to the database and I loose access to performing commit or rollback on the specific transaction. Arrrggghh. | Dec.16-17 1998 |