Essentia Tips and Tricks

The majority of the ``tips and tricks'' that will be explained in this Appendix are oriented to minimize the communication bewteen the server and the client to reduce overhead.

The communication between the server and the client varies basically depending on two variables. The first one is the number of instructions (methods) the client asks the server to be executed. The second is know with the name ``buffering'', which means to send the server more than one method (and the information corresponding to each of the methods sent) in the same message.

  • The only "bufferable methods" are those from which the client doesn't receives answer. Those are:

    It is convenient to execute the highest possible number of bufferable methods together, until the buffer is full or until a non-bufferable method has to be executed.

  • Use Cursors

    The use of cursors is very important because it allows to bring pages of records. Each message to the server brings a group of records, insetad of only one, like with GetRecord.

  • Use IO_KEY_FIELDS

    Using the flag IO_KEY_FIELDS allows to bring up only those fields of the key upon whe the cursor was created, minimizing the data transported and maximizing the number of information that appears in the read pages.

  • Use SetCursorFlds

    The routine SetCursorFlds brings only the specified fields of a given table, minimizing the data transported and maximizing the number of information that appears in the read pages.

  • Use UpdateRecord

    UpdateRecord allows to perform operations over one or more fields of a table without transmitting the entire record.

  • Use SetTableCache

    SetTableCache is desgined exactly to access those tables were obtaining the las stored information isn't necesary (e.g., codifier tables). It minimizes the number of messages to the server maintaining in memory the records and doing a local search --i.e., in the client-- of them.

  • num(9) vs. num(8)

    In the IDEAFIX programming community, there exists a tradition in respect to numerical fields:

  • Use of SetRelation

    When using this function, many GetRecord will be executed for each record read. Because of this, the programmer has to be very careful when deciding to use it. If the programmer doesn't know exactly the number of accesses he's defining, he can degrade performance because of the large number of unnecessary readings.

  • Use of Arrays

    You have to be very careful when defining arrays within the database, because they may increment too much the table's record length, bringing forth performance problems.

  • Transactions (Locks, PutRecord, DelRecord)

    When working with Essentia as a database engine, a good use of the transaction mechanism is vital, and the applications have to be designed having this into account. A transaction is a program unit whose execution maintains the consistency of the database. To guarantee this, transactions must be atomic, i.e., all the instructions it implies are executed, or none of them does. Note that the programmer is in charge of defining programs that use the transaction mechanism correctly.

    If the programmer doesn't define the transactions, each function that modifies the database (i.e., PutRecord, DelRecord, UpdateRecord, BuildIndex, etc.) will be considered an independent transaction, i.e., the cfix Essentia access library will perform automatically the necessary BeginTransaction and EndTransaction operations.

    This--which generally isn't desired-- implies two disadvantages: greater number of methods ``traveling'' to Essentia, and a restriction of the possibility of buffering the operations, because BeginTransaction and EndTransaction aren't bufferable.

    Let's see an example were a simple mistake con increment considerably the number of messages sent to the server:

    
    Total number of messages: 2.
    
    
    Total number of messages: 10.
    
    This difference in the number of messages may not make big difference when the client is running locally, but when the client is remote (specially if these sequence of instructions is inside a loop) the difference is clear. This effect will be also clear in a network were a ping takes 2 to 3 seconds from one machine to another.

  • Locks

    In Essentia, to preserve the consistency of the database, the locks made during a transaction are not released until that tarnsaction ends. This may bring that, badly designed programs, with long transactions and massive locks (that may overload the lock table), are prevented from executing.

    This type of transactions have to be redesigned to make locks at a table's level (instead of record) or they have to be divided into smaller transactions.

  • PutRecord

    Each PutRecord performed on the database generates a lock on the updated record, thus allowing Essentia to maintain the logic consistency of the transactions. This means that transactions that work with PutRecord have the same problems as in the previous topic, and then the same considerations apply.

  • DelRecord

    When using the DelRecord function, the erased records aren't deleted until the end of the transaction, because they must remain locked. In the case of massive deletings this generates overhead, that can be avoided locking all the table were the deletions are made.


    Next Page Table of Contents