Kbase 18064: Max Number Of Users Increases to 4000 in 8.3A
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
6/29/1998 |
|
Max Number Of Users Increases to 4000 in 8.3A
The Progress Database engine has always had a limit of 2048 users. The
biggest reason for this is the method by which Progress goes through
undo-redo processing, and this process is well documented in KB13866.
Basically what this process entails is keeping track of active
transactions in the bi file, and then recreating these transactions
in the event that they don't get completely committed. If the
transaction is not committed, then Progress will undo the transaction
based on the notes it kept in the bi file. This feature is the single
most important component in our fight against database corruption in
the event of a crash. This article will attempt to explain how the
process works now as well as how it has been enhanced in version 8.3.
Progress creates a table in memory called the transaction table. This
table has one entry for every user defined by the -n startup
parameter. Each transaction is identified in this table by its
transaction slot number. When we write this slot number to a note in
the bi file, we we use a unique transaction id that we use to recreate
the transaction table during crash recovery and then take the
appropriate action with that transaction. The current upper limit to
the number of possible entries in the transaction table is 2048, and
this is also the upper limit to the number of concurrent database
transactions. The reason for this is we write the transaction id to
the data portion of the bi note(header), and obviously this is not an
unlimited space. It's limit happens to be the byte equivalent to the
transaction id's of 2048 concurrent transactions.
Since the bi note header is not an unlimited space and we want to
push the upper limit, we have a bit of a problem with the way the bi
file currently deals with writing all of these transaction id's. A
checkpoint is the point in time when these notes are written, and the
way the bi functions now, we don't have a problem getting all of the
transaction information written in one checkpoint because we always
know all the transaction id's data will fit into a note. Now that we
increased the amount of possible concurrent transactions without
increasing the data capacity of a note, we will no longer be able to
write all the transaction information within one note. Instead we will
have to write the currently active transaction id's as several notes.
The term used in describing the multiple note implementation is
Segmented Checkpoint. Undo processing will still use the transaction
id to recreate the transaction table, but it will now use several
notes instead of one in the recreation process. Since we are changing
the mechanism that is writing to these notes, we will obviously have
to do some kind of conversion on the bi file.
Using the proutil dbname -C truncate bi qualifier that is shipped with
version 8.3A will convert the bi file and facilitate the necessary
changes for implementing the segmented checkpoint.
NOTE: If connecting to a non 8.3 db with an 8.3 client, the database
must be truncated with the 8.3 proutil or the connection WILL FAIL. If
you forget to truncate and get an error, you will then be able to
issue the 8.3 truncate bi, and then be allowed access to the database.
The exact error message you will recieve is the following:
You must truncate the bi before 1st 83 connection
SDA 6/29/98