About Transactions

Topics:

About Transaction Behavior

While a write operation is being performed on a table, the following occurs:

  • Queries to the table are executed against the state of the database before the write operation began. Once the current LOAD or INSERT/UPDATE/DELETE is complete and the operation is committed, then subsequent queries execute against the new state of the database.
  • Until the current write operation is committed, all subsequent write commands to the table are queued. They will wait for the write lock to be released before proceeding in the order they were received.

While a read query is being executed on a table, the following occurs:

  • All subsequent queries run concurrently with the current query.
  • A subsequent LOAD or INSERT/UPDATE/DELETE will run concurrently with the current queries. Further write operations with queue (as described above).

In general, Hyperstage uses table-level locking where only one write operation (INSERT, UPDATE, DELETE, or LOAD) can execute at one time.

Failure Handling

If the Hyperstage server (ibengine) is terminated during an export operation to a disk file, the following occurs:

  • A non-empty file is saved on disk. However, the last row in the saved file is inconsistent.
  • The database files are not harmed by the failed export operation. To export data, repeat the export operation.

If Hyperstage tries to import data from a file created during a failed export session, the following occurs:

  • No data is inserted because the input file consists of corrupted table rows. No new records are added to the database files, so no harm is done.

WebFOCUS

Feedback