Session Control

The Session Control manager, available from the main window's pop-up menu, shows a graphical representation of the transaction history of the database. The user must be listed in passwd.wrm to access the tool. Its main importance is to allow rollback or data recovery and to provide a means for preserving specific sessions from destruction. Transaction details for session are recorded in the database log file. Together with the original data files, it should be possible to determine what was contained by a particular session.

In general, every cycle of write access...save leaves behind a numbered session. This includes the very first session which is created upon reinitialization. The current session ("This_session" in the Session Control Manager window) always descends from one of the historical sessions even if no modifications have been made since the last save. Note that taking write access and then saving without actually making changes does not create a session. In addition, quitting and restarting the database does not create a session

Numbered sessions can be "alive" (available for rollback), "alive and fixed" (available for rollback and preserved) or "dead" (unavailable for rollback). Any living session can be fixed, and fixed sessions can be unfixed. The default is to kill all sessions other than session 1 and the two most recent numbered sessions. Therefore, unless the curator intervenes to fix sessions, recovery options are limited.

Note that rollback is not implemented in a way which allows the curator to begin working from a previous session, i.e. to return to it and then add or delete data. Instead, rollback provides a read-only view of the past. Full recovery involves dumping the historical view, reinitializing and then reloading the dump. History is lost in this process, i.e. the new database will not know about its previous incarnations.

The most recent numbered session can also be destroyed. Unlike rollback, this is an irreversible act; if chosen the database reverts to the next available session and exits. The database restarts with this session and its descendent no longer exist. The same thing can be accomplished without as much finality using rollback, albeit with a dump and a new database.

Another limitation concerns models. If the models are changed, it is still possible to roll back to a version created prior to the change and either view the database in read-only mode or dump it. However, the models are never dumped, so you will need the earlier version of models.wrm to recreate the database.

The Session Control Manager shows a forked path when rollback occurs. Both the current session and the original session descend from the same ancestor (this is illustrated below). In addition, all dead sessions descend from session 1.

The steps below show the history of a small database.

Freshly reinitialized with these models:

?Publication Title Text

"This_session" descends directly from session 1. The log file contains

New start:1997-07-15_14:18:19 Host:coyote Pid:5726
**********************************************************
Making a new database file and starting at session 1 again
1997-07-15_14:18:21: Now  3968 blocks , 3968 in partition block1.wrm
SAVE SESSION 1 1997-07-15_14:18:21
Take write access, read in one .ace file and save:

Publication A
Title "First Title"

Publication B
Title "Second Title"

Publication C
Title "Third Title"

Publication D
Title "Fourth Title"

"This_session" now descends directly from session 2. The following has been appended to the log file:

Write access.  User:scartinh Session:2 Host:coyote Pid:5726
// Parsing file /rusty/dbs/testdb/rawdata/test.ace
SAVE SESSION 2 1997-07-15_14:22:14
Read in another .ace file and save:


Publication A
-D Title "First Title"
Title "1st Title"

Publication E
Title "Fifth Title"

"This_session" now descends directly from session 3. The following lines have been appended to the log file:

Write access.  User:scartinh Session:3 Host:coyote Pid:5726
// Parsing file /rusty/dbs/testdb/rawdata/test2.ace
SAVE SESSION 3 1997-07-15_14:26:07
The database now contains five publications, A through E, and A is the modified version:

Now return to session 2. Select the session, then click the "Start Session" button. This will dismiss the session window. When it is invoked again, we see

"This_session" descends directly from session 2. So does session 3 but it is now a branch off the session history path.

The database at this point is read-only; attempts to gain write access will be ignored. It contains the contents of session 2, i.e. publications A through D with the earlier version of A:

The session 2 database cannot be further modified, because write access is unavailable, but it can be dumped:

// data dumped from keyset display

Publication : "A"
Title	 "First Title"

Publication : "B"
Title	 "Second Title"

Publication : "C"
Title	 "Third Title"

Publication : "D"
Title	 "Fourth Title"
Quitting the database returns it to its pre-rollback status, i.e. "This_session" is the direct descendent of session 3.
We now modify the models and read them in:

?Publication Name Text

Reading in the new models and saving has established session 4. Session 2 is now dead to satisfy the default rule that only the most recent two sessions are alive. The destruction of session 2 could have been prevented by fixing it prior to reading in the new models.

Mature databases can have large numbers of dead sessions associated with session 1. This is not a problem.

These lines have been appended to the log file:

New start:1997-07-15_15:03:54 Host:coyote Pid:5780
Write access.  User:scartinh Session:4 Host:coyote Pid:5780
SAVE SESSION 4 1997-07-15_15:04:04