}

}

}

}

}

This example application works in the following ways:

The first step is to get all hosts out of the 

ACCESSLIST

 table from which the 

specified user has access to the requested function.

The second step is to insert the information about the access request into the 

table 

APPLACCESS

. The main reason for this step is that if this information is 

stored in a table, the SQL 

LIKE

 function can be used in the next step. The 

LIKE

 function handles wildcards ('

%

' and '

_

') in the host information correctly.

The third step is to verify if the host name or IP address has the access rights 

by comparing the entry with the host name retrieved in the first step.

If so, access is allowed and the function should be executed. You can also 

implement a method that has a return code telling if access is allowed or not.

7.3  Additional application considerations

Once converted to DB2 Version 8.1, an application's run time performance can 

be impacted by a number of factors. The following section describes what locking 

and transaction isolation does to your application when running in a multi user 

environment.

7.3.1  What is the purpose of locking?

When many users access the same data source through your application, or any 

other interface that allows data manipulation, some unwanted effects may occur. 

These effects are called:

Lost update: 

Two concurrent users retrieve and update the same data. The last successful 

change is kept while the first change is overridden.

Uncommitted (or dirty) read: 

User A can read or view data changed by User B, but those changes have not 

been committed yet.

Non repeatable read: 

Within the same transaction User A runs the identical SELECT statement 

multiple times with different results because User B 

modified

 records in User 

A's result set.

226 

MySQL to DB2 UDB Conversion Guide