Informix performance and locking

An important consideration when designing a database application is deciding when connect and commit statements should occur to maximize performance and limit locking and resource use. A connect takes a certain amount of time and can tie up resources during the life of the connection. If this time is significant, then limiting the number of connects is desirable.

After a connection is established, SQL statements can cause locks to be placed on database entities. The more locks there are in place at a given moment in time, the more likely it is that the locks will hold up another transaction.

Rules

No set of rules for designing a database application is totally comprehensive. However, when you design a PowerBuilder application, you should do the following:

Isolation feature

Informix-OnLine databases use the isolation feature to support assorted database lock options. In PowerBuilder, you can use the Lock property of the transaction object to set the isolation level when you connect to the database.

The following example shows how to set the Lock property to Committed read:

// Set the lock property to committed read
// in the default transaction object SQLCA.
SQLCA.Lock = "Committed read"

NoteInformix-SE databases do not support Lock The Lock property applies only to Informix-OnLine databases. Informix-SE (Standard Edition) databases do not support the use of lock values and isolation levels.

Example 1

This script uses embedded SQL to connect to a database and insert a row in the ORDER_HEADER table and a row in the ORDER_ITEM table. Depending on the success of the statements in the script, the script executes a COMMIT or ROLLBACK:

// Set the SQLCA connection properties.
SQLCA.DBMS = "IN9"
SQLCA.database = "ORDERS"// Connect to the database. 

CONNECT USING SQLCA;
// Insert a row into the ORDER_HEADER table.
// A ROLLBACK is required only if the first row 
// was inserted successfully.

INSERT INTO ORDER_HEADER (ORDER_ID,CUSTOMER_ID)
	VALUES ( 7891, 129 ); 

// Test return code for ORDER_HEADER insertion
if SQLCA.sqlcode = 0 then

// Since the ORDER_HEADER is inserted,
// try to insert ORDER_ITEM
	INSERT INTO ORDER_ITEM 
		(ORDER_ID, ITEM_NBR, PART_NBR, QTY)
		VALUES ( 7891, 1, '991PLS', 456 ); 

// Test return code for ORDER_ITEM insertion.
	if SQLCA.sqlcode = -1 then

// If insert failed
// ROLLBACK insertion of ORDER_HEADER.
	ROLLBACK USING SQLCA;
	end if
end if

// Disconnect from the database. 
DISCONNECT USING SQLCA; 

NoteError checking Although you should test the SQLCode after every SQL statement, these examples show statements to test the SQLCode only to illustrate a specific point.

Example 2

This example uses the scripts for the Open and Close events in a window and the Clicked event in a CommandButton to illustrate how you can manage transactions in a DataWindow control. Assume the window contains a DataWindow control dw_1 and the user enters data in dw_1 and then clicks the Cb_Update button to send the data to the database.

Since this script uses SetTransObject to connect to the database, the programmer is responsible for managing the transaction.

Window Open event script

// Set the transaction object properties
// and connect to the database. 
// Set the SQLCA connection properties. 
SQLCA.DBMS = "IN9"
SQLCA.database = "ORDERS"

// Connect to the database. 
CONNECT USING SQLCA;

// Tell the DataWindow which transaction object 
// to use. 
SetTransObject( dw_1, SQLCA ) 

CommandButton Clicked event script

// Declare ReturnValue an integer.
// integer	ReturnValue
ReturnValue = Update( dw_1 )

// Test to see if updates were successful.
if ReturnValue = -1 then

// Updates were not successful. Since we used 
// SetTransObject, rollback any changes made 
// to the database. 
	ROLLBACK USING SQLCA;
else


// Updates were successful. Since we used 
// SetTransObject, commit any changes made 
// to the database. 
	COMMIT USING SQLCA;
end if

Window Close event script

// Disconnect from the database.
DISCONNECT USING SQLCA;