FairCom ISAM for C

Optional Defer of Close Until Transaction Commit/Abort

FairCom DB supports the ability to defer file closes and deletes during transactions until the transaction is completed or aborted. This allows more flexible file handling without worrying about whether a transaction-controlled file was currently involved within a transaction. SetOperationState() can change the behavior of a file close request when the file has been updated as part of a still active transaction. Turning on OPS_DEFER_CLOSE causes defers a file close or delete until the transaction is committed or aborted.

Updates by other clients do not affect the “update status” of a file for a client who has not updated the file within a transaction.

For example:

OPEN FILE A client #1

OPEN FILE A client #2

OPEN FILE B client #2

SETOPS (OPS_DEFER_CLOSE, OPS_STATE_ON); client #1

SETOPS (OPS_DEFER_CLOSE, OPS_STATE_ON); client #2

TRANBEG client #1

TRANBEG client #2

READ FILE A client #1

UPDATE FILE A client #2

CLOSE FILE A (succeeds without defer) client #1

CLOSE FIL A (deferred) client #2

UPDATE FILE B (suceeds without defer) client #2

TRANEND (causes a CLOSE ON FILE A) client #2

CLOSE FILE B client #2

TRANEND client #1

This example shows that client #2’s update does not cause a defer when client #1 closes file A within a transaction in which client #1 had not updated file A, but client #2’s close is deferred.

• A request to reopen the file with the same file number within the same transaction will be honored.
• An attempt to reopen the file with a different file number within the same transaction will be honored, provided there is no overlap with the original file numbers due to index members.
• An attempt to open a different file with the same file number or overlapping file numbers will fail.

For example:

OPEN A as file #2 (where A has two additional index members)

OPEN B as file #10

SETOPS(OPS_DEFER_CLOSE,OPS_STATE_ON)

TRANBEG

UPDATE A

CLOSE A (deferred: file #s 2,3 and 4 still in use by A)

UPDATE B

OPEN A as file #2 (succeeds since same file reusing file numbers)

UPDATE A

CLOSE A (deferred: file #s 2,3 and 4 still in use by A)

UPDATE B

OPEN C as file #2 (fails because of defer on file A)

OPEN A as file #0 (fails because of overlap with itself)

OPEN A as file #9 (fails because of overlap with B)

OPEN A as file #5 (succeeds)

OPEN C as file #2 (succeeds because file A now reassigned)

There are restrictions on file mode changes between a deferred close and a subsequent reopen within the same transaction. A file originally opened in exclusive mode can be reopened in ctSHARED mode. A file originally opened in ctSHARED mode must be reopened in ctSHARED mode. ctREADFIL is not allowed on a reopen.

Notes

• ctEXCLUSIVE reopen of a deferred close of a ctSHARED file - If a file opened ctSHARED has its close deferred, and an attempt is made to “reopen” the file in ctEXCLUSIVE mode, the reopen will now succeed under the Server if no one else has the file opened. For example, the second open below succeeds only if no other user has the file open.

datno = OpenFileWithResource(,ctSHARED);

Begin;

DO_Stuff();

CloseIFile(datno);

datno = OpenFileWithResource(,ctEXCLUSIVE);

Commit();

Here are the expected results for deferred close and subsequent open requests:

Current status	Same user	Another user
Deferred close after ctEXCLUSIVE open	May reopen the file in ctEXCLUSIVE or ctSHARED mode	Cannot open file
Deferred close after ctSHARED open	May reopen the file in ctSHARED mode. May reopen the file in ctEXCLUSIVE mode if no other user has the file open.	May open the file in ctSHARED mode

• File number change after deferred close - In single-user TRANPROC, a deferred close followed by a reopen with a different file number returns CHGF_ERR (645). To avoid this error, always re-open using the same file number. For ISAM files, this is easily accomplished using OpenFileWithResource() with a -1 for filno or using OpenIFile() with an IFIL structure setting dfilno to -1.