ED101

ObjectStore Design and Development

Lab Exercise 0: Getting your feet wet with ObjectStore

OBJECTIVES

Use available utilities and tools to verify the ObjectStore development environment and databases. Introduction to the ObjectStore Inspector and Performance Expert Tools.

APPROXIMATE TIME

30 minutes

Part I Verify the ObjectStore Environment

One of the best ways to become acquainted with the ObjectStore environment is to browse existing databases using available tools and utilities. The utilities ossize and osverifydb provide important information about database structure and content.

  1. Type ossvrstat from the command prompt.

    2. Current version of the ObjectStore server is ________________.

  2. Locate the ObjectStore distribution.
  3. Change directory to examples.
  4. Execute "doall" in the coll directory. ( If this is not available in the ObjectStore installation on your machine, ask the instructor for an alternate way to check the setup )
  5. Execute "osverifydb" on the coll.db.
  6. Execute "ossize" on the coll.db.

Size of coll.db is ____________.

Part II Inspect an ObjectStore Database

The ObjectStore Inspector provides a way to access databases for activities such as browsing, testing and verifying databases, editing data, and performing ad hoc database queries and analysis without writing a single line of code. For this exercise, we will learn how to locate important information about how a specific database has been implemented which will assist us in completing future labs. Using any tool you know, fill up the following blanks :

  1. DB was created on a machine.
  2. DB has database root(s), named .
  3. DB has segments.
  4. There is % free space in segment 2.

Use the ObjectStore Performance Expert Tool

The ObjectStore Performance Expert is a visual tool which provides feedback on the ObjectStore client and server processes.

  1. Execute "osopes" to invoke the Server Monitor.
  2. Execute "osopea" to invoke the Analyzer.

At this time, we have not created the client trace file that opea requires. You may use the example trace files that accompany this tool to analyze a sample client application run.

ED101

ObjectStore Design and Development (C++)

Lab I : On being persistent

Objective : To make an object (of a user-defined class) persistent, and to manipulate it

  1. Write a program Creator to open an account with OSBank . Take the password and initial deposit as input. Make OSBank.db the database filename. Let the Account consist of the balance and the password . (For simplicity, let password be a four digit number)

    2. Sample Input/Output for Creator :

    Creator> Password: 1234

    Creator> Initial deposit (in dollars): 1000

    Creator> You have opened an OSBank account with $1000

  2. Write a program Accessor that allows the user to view the balance, withdraw, deposit or close the OSBank account. Run Accessor repeatedly selecting a different option from the menu each time.

Sample Input/Output for Accessor :

    1. View Balance
    2. Withdraw
    3. Deposit
    4. Close Account

Accessor> Enter Choice: 2

Accessor> Password: 1234

Accessor> Withdrawal amount : 400

Accessor> $400 withdrawn. Your current balance is $600

Note that there is no loop in the Accessor program.

  1. (Extra Credit
    2. )
    1. Run the Accessor in multiple windows and observe the effects.
    2. Combine the Creato r and the Accessor into one program (adding the option Create a new account to the menu in the process) in a way that causes no Exceptions.

ED101

ObjectStore Design and Devleopment

Lab II : From persistent to persistent

Objective :

Modify the Account class from Lab I to include two more fields. These two fields are pointers ( pLeft, pRight ) to other Account objects. Create three persistent accounts A , B and C and set them up in such a way that A 's pRight points to B , B 's pRight points to C , C 's pLeft points to B and B 's pLeft points to A .

Your program is going to move back and forth between A , B and C , making modifications to the balance in the accounts in the process. Start by positioning yourself at A .

The first line of the input file contains three integers. Use these to initiliaze the balance in the accounts A , B and C respectively.

For each character in the input file, perform the operation specified below :

+ Add the balance in the account on your right to your balance

- Subtract your balance from the balance in the account on your left, and set your balance to the result

R Move to the account on your right

L Move to the account on your left

When you encounter the end of the file, output all the three balances.

ED101

Objectstore Design and Development (C++)

Lab III : On Collecting

Objective :

King Klong's Cabinet

  1. King Klong's ministry consists of 26 people, each with a unique talent. Each minister is named after a letter of the English alphabet because the King can not remember their real names. To manage his ministry, King Klong requires you to write a program that provides the following menu of options:
    1. Black-mark
      2. 4 ministers to behead
    2. Behead all
      3. blackmarked ministers
    3. Display current
      4. ministry
    4. Display blackmarked
      5. ministers still alive
    5. Quit
      6. Program

A black-marked minister is beheaded if any of these conditions is satisfied:

    1. The minister has been black-marked 3 times
    2. King Klong issues the Behead all command (option 2 in the menu)

Note that King Klong might quit the program after black-marking 4 ministers, and run the program again later.

You are provided with an input file ministers.txt , where each line is of the format < Name> <Talent>

(e.g. " X Can lie through his teeth ").

Do not leave any corpse lying around in the ministry.

II. ( Extra Credit )

    1. Modify your program to behead a minister on a third condition : being black-marked in two consecutive runs of the program. In this case, the minister should be beheaded immediately after he is black-marked the second time.
    2. Modify the input file – Change the names to contain two letters instead of one. Modify your program so it can work with any number of ministers.
    3. For each beheaded minister add two new ministers. Form their names by appending "I" and "II" to his/her name. Do not consider them for beheading.

ED101

ObjectStore Design And Development (C++)

Lab IV: On Collecting

Objectives :

The Dating Game

There are two kinds of users in this Dating System : Seekers and Singles . Each line in the input file Singles.txt describes a person.

ID Sex YearofBIrth Height Y/N

Create a Person object from each of these lines, and insert this object into the Singles collection. The Person class must also consist of a method that returns a Yes or No at random (Let's pretend that this is the person's answer to the question "Do you believe in instant love?" ).

Another file Seeker.txt contains, in each line, the name of a Seeker , and the profile of person sought. The program has to find all the matches and list them. Each line in Seeker.txt takes the following format

ID Sex Age-range Height-range Y/N

ID is the id of the Seeker (It is a 4-digit integer )

Sex is the sex of the Seeker

Age Range and Height Range pertain to the person sought

Y/N part is the answer sought, for " Do you believe in instant love? "

Sample lines from Singles.txt :

1111 M 1972 65

2222 F 1954 70

Height is in inches.

Sample lines from Seeker.txt :

3333 M 27 35 60 70 N

4444 F 34 53 70 80 Y

For each Seeker, list all Singles that match him/her.

ED101

Lab Exercise 5: Transactions and Concurrency

OBJECTIVES

APPROXIMATE TIME

60 minutes

OVERVIEW

When first using ObjectStore, it is not always clear exactly how multiple clients accessing the same database will behave in concurrent scenarios. There are many options to explore, including the standard read/write locking model, nested transactions, read locks, write locks, etc. In addition, read-only clients can use multi-version concurrency control (MVCC) to avoid lock conflicts altogether. The intention of this lab is to demonstrate exactly how ObjectStore handles locking in concurrent situations, especially with and without MVCC.

Instructions

In this lab, you will run multiple clients of the same application using the same database, and observe the results of scenarios that cause lock conflict under various conditions. You will also observe the behavior of nested transactions in different scenarios.

The database for this lab is very simple. It consists of two database roots, each pointing to an instance of the class Counter. Counter is a class that has one data member, an int whose value is initially 0. The two instances of Counter, referred to as "counter1" and "counter2," are each allocated in separate segments. By attempting to increment the specified counter, a client application will have to obtain a write lock on the page containing the counter. The value of each counter is used to show you the results of different scenarios. Feel free to experiment with your own scenarios—the ones provided are just to get you started.

1. Build the application. Unlike all the other exercises, the executable for this exercise is named "transact".

2. Start two command shells and execute a version of the application in each window, using the same database:

Window 1: transact test.db

Window 2: transact test.db

3. Follow the scenarios described below. Window 1 is identified as "W1" and Window2 is identified as "W2". Follow the instructions, in order, and observe the results. The menu that will appear is shown below:

Transactions and Concurrency

_______________________________

1. ...Open Database (Read/Update)... // close/reopen database

2. ...Open Database (MVCC Read-Only)... // close/reopen for mvcc

3. ...Begin Transaction... // nested transactions allowed

4. ...Commit Transaction...

5. ...Abort Transaction...

6. ...Read counter1... // read-lock counter1 (write if new db)

7. ...Increment counter1... // write-lock counter1

8. ...Read counter2... // read-lock counter2 (write if new db)

9. ...Increment counter2... // write-lock counter2

10. ...Display counters... // read-lock both counters

11. ...Close database and quit...

Enter choice (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, or 11):

Scenario 1: Lock wait on creation

W1: Open Database (Read/Update)

W1: Begin Transaction

W2: Open Database (Read/Update)

W2: Begin Transaction

W1: Read counter1 // this will write-lock counter1 because it is created here.

W2: Read counter1 // conflict

W1: Commit Transaction

W2: Read counter2 // do this to create counter2.

W2: Commit Transaction

Scenario 2: Lock wait on update

W1: Begin Transaction

W1: Increment counter1

W2: Begin Transaction

W2: Read counter1 // conflict

W1: Commit Transaction

W2: Commit Transaction

Scenario 3: Deadlock

W1: Begin Transaction

W1: Read counter1

W2: Begin Transaction

W2: Read counter1

W1: Increment counter1 // conflict

W2: Increment counter1 // deadlock

One process will be the deadlock victim. It will automatically restart due to the err_deadlock exception. For the remaining running process, commit the transaction.

Scenario 4: Nested transactions (abort inner transaction)

W1: Begin Transaction

W1: Read counter1

What is counter1's value? _____

W1: Begin Transaction // nested transaction

W1: Increment counter1

What is counter1's value? _____

W1: Abort Transaction

W1: Read counter1

What is counter1's value? _____

W1: Commit Transaction

Scenario 5: More nested transactions (abort outer transaction)

W1: Begin Transaction

W1: Read counter1

What is counter1's value? _____

W1: Begin Transaction // nested transaction

W1: Increment counter1

What is counter1's value? _____

W1: Commit Transaction

W1: Read counter1

What is counter1's value? _____

W1: Abort Transaction

W1: Begin Transaction

W1: Read counter1

What is counter1's value? _____

W1: Commit Transaction

Scenario 6: MVCC

This one may take some time to figure out why the counter values are what they are in each instance. The transaction duration are mapped out as lines along the right side in order to help clarify which transaction is currently active. Each time you are asked for the counter value(s), make sure you understand why each value appears as it does.

W1 Txns W2 Txns

W1: Open Database (MVCC Read-Only)

W2: Open Database (Read/Update)

W1: Begin Transaction begin

W1: Read counter1 |

What is counter1's value? _____ |

W2: Begin Transaction | begin

W2: Increment counter1 // conflict | |

What is counter1's value? _____ | |

W1: Display counters | |

What is counter1's value? _____ | |

What is counter2's value? _____ | |

W2: Display counters | |

What is counter1's value? _____ | |

What is counter2's value? _____ | |

W2: Commit Transaction | commit

|

W2: Begin Transaction | begin

W2: Increment counter2 | |

What is counter2's value? _____ | |

W1: Display counters | |

What is counter1's value? _____ | |

What is counter2's value? _____ | |

W2: Display counters | |

What is counter1's value? _____ | |

What is counter2's value? _____ | |

W1: Commit Transaction commit |

|

W1: Begin Transaction begin |

W1: Display counters | |

What is counter1's value? _____ | |

What is counter2's value? _____ | |

W2: Commit Transaction | commit

|

W1: Display counters |

What is counter1's value? _____ |

What is counter2's value? _____ |

W1: Commit Transaction commit

W1: Begin Transaction begin

W1: Display counters |

What is counter1's value? _____ |

What is counter2's value? _____ |

W1: Commit Transaction commit

Scenario 7: More MVCC

In a third window, start a third client. Make sure all outstanding transactions are committed. The third client will be known as "W3". As in the previous scenario, make sure that you understand why each value appears as it does to each of the clients.

W1 Txns W2 Txns W3 Txns

W1: Open Database (MVCC Read-Only)

W2: Open Database (Read/Update)

W3: Open Database (Read/Update)

W1: Begin Transaction begin

W2: Begin Transaction | begin

W1: Read counter1 | |

What is counter1's value? _____ | |

W2: Increment counter1 // conflict | |

What is counter1's value? _____ | |

W2: Commit Transaction | commit

|

W1: Display counters |

What is counter1's value? _____ |

What is counter2's value? _____ |

|

W3: Begin Transaction | begin

| |

W3: Increment counter2 | |

What is counter2's value? _____ | |

W3: Display counters | |

What is counter1's value? _____ | |

What is counter2's value? _____ | |

W1: Display counters | |

What is counter1's value? _____ | |

What is counter2's value? _____ | |

W1: Commit Transaction commit |

|

W1: Begin Transaction begin |

W1: Display counters | |

What is counter1's value? _____ | |

What is counter2's value? _____ | |

W3: Commit Transaction | commit

|

W1: Display counters |

What is counter1's value? _____ |

What is counter2's value? _____ |

W1: Commit Transaction commit

W1: Begin Transaction begin

W1: Display counters |

What is counter1's value? _____ |

What is counter2's value? _____ |

W1: Commit Transaction commit