DB2 provides support for three levels of multiple user concurrency control. These isolation levels select the extent to which database operations performed by one user are isolated from concurrent operations performed by other users.
“Repeatable Read” isolation level means that locks are held on all rows read or updated by a user for the duration of the current transaction (or logical unit of work). At this isolation level, if a row is read at some time and at a later time during the same transaction is re-read, the row still contains the same data values. That is, within a transaction, a read of a row is “repeatable” with identical results.
“Cursor Stability” isolation level means that within a transaction, locks are held only on the most recently read row or rows. Were a row that had been previously read within a transaction to be re-read, there is no guarantee that it returns the same column values as previously as another user could have updated the row in the meantime.
“Uncommited Read” isolation level means that within a transaction, rows that have been updated by one user can be read by another user and the reading user sees the updated values. The updating user may later decide to cancel the transaction, in which case the reading user would have retrieved (and possibly made decisions based on) data that is no longer stored in the database.
In general, the cursor stability isolation level is appropriate. However, in cases where updates are being performed on tables that are being related to themselves (reflexive relationships), the repeatable read isolation level should be selected, as it is highly probable that previously read rows will be re-read.
Zim can manipulate and retrieve data from third-party data sources as well as from a Zim database. Client applications for SQL database servers are designed and developed as complete Zim application systems. The objective of the Zim product is 100 percent source code portability of applications including seamless access to databases being managed by SQL relational database management systems (SQL servers) supplied by independent vendors. In fact, a Zim Client-Server database application can consist of an arbitrary mixture of tables managed by an SQL server and entity sets and relationships managed by Zim.
As an architectural model, client-server architecture consists of two components: a server process and a client process. A server process provides services to client processes, whereas a client process requests services from a server process.
A database management system is a server process that provides database access and update services to application programs (client processes). Any application program that issues database requests to a database management system is a client-server database application. The database server can be on the same machine as the application program, it can be a database server on a local area network; or it can be on a host machine with access through a gateway. In all cases, the application program is acting as a client and the database management system is acting as a server.
In order to use the client-server capabilities of Zim, two software components are required:
Zim software
The JDBC SAM (Server Access Module) which makes a “bridge” between the Zim application and the specific SQL database server in use. Any SQL database servers available in the market allow the JDBC connection, both in 32 or 64 bits.
A Zim Client-Server application can be developed as a stand-alone standard Zim application on any supported platform. Once developed, the application can be moved easily to another platform and configured to access remote data sources. Because of this capability, Zim enables you to separate your application from the ultimate data source, enabling development to be done independently of the target database management system or platform. Zim lets you perform application development and testing off-line on a stand-alone PC, a portable, or a workstation and then implement the production application on a Zim database, an SQL database, or a combination of both. This reduces the demands on your environment, including your SQL database. This portability lets you perform your development and testing on one hardware platform and implement as a client application on a completely different platform.
Zim applications can process data stored in more than one location. Database servers often become performance bottlenecks because data is located in one area and the server cannot handle the processing load for that data. Zim avoids this bottleneck by letting you distribute or partition data elements across both the database server and the Zim databases. This gives you the power to balance the load on your network. By off-loading data from your server, Zim boosts performance by lowering server demand.
Client-Server database application development with Zim provides application portability to database servers. An application written for a particular server can be migrated to another server without changes to the application. Zim portability lets you adopt new technologies as they emerge.
Zim lets clients on different platforms run the same application against the same database server concurrently. Clients can be moved to other platforms. The client platforms for an application can be mixed and matched, as required.
Zim provides a universal interface to database servers. Zim still enables you to access the unique features and strengths inherent in any database server by taking advantage of proprietary extensions of the SQL dialect. Zim syntax supports any SQL database in an optimal way.
Zim enables you to test your applications interpretively, without compiling first.
If the Zim application being developed is based on an existing SQL database, then the Zim definition interface needs to be executed in order to import the definitions of the relevant tables from the SQL server and populate the Zim data dictionary so that the application can be developed.
Conversely, if the Zim application has been developed, but the database is not already resident in the SQL server, then the Zim definition interface would be invoked to export the Zim EntitySet and data relationship definitions to the SQL server. For some SQL servers, this requires a new database on the server. This is accomplished using a utility program/facility provided with the SQL server.
The Zim definition interface only imports and exports definitions. There is no facility to keep the Zim definitions and the SQL servers definitions in sync after they have been imported or exported. Any changes to definition in one must be made explicitly in the other. Failure to do so leads to unexpected results and errors.
Zim supports two types of transactions: implicit and explicit. An implicit transaction is associated with each individual Zim command that accesses the database in some manner (either read/only or read/write). When the command ends, all locks that were acquired are released and any database updates are committed to the database. If the command fails (e.g. a deadlock condition), then Zim automatically removes any partial updates and releases all locks.
Explicit transactions are provided in order to support database updates associated with multiple database access commands that must either be all committed or all removed as a single “logical unit of work” (or “logical unit of recovery”). An explicit transaction is initiated by the command “transaction” and ended either by the command “endtransaction” (that commits any database updates) or by the command “quittransaction” (that cancels any database updates). Both commands release all held locks. Should any database access command inside an explicit transaction fail (e.g. by a deadlock condition) then all partial updates to that point are removed and all held locks are released.
Zim supports this “transaction” functionality against an SQL server database.
In Client-Server applications, you do not have to do anything special to access or manipulate data stored in the SQL database. The data definitions of objects under Zim’s control and the data definitions of objects not under Zim’s control are exactly the same. To an application, Zim manipulates both in exactly the same way.
The development of a Zim Client-Server application can be performed in isolation from the SQL database; it can in fact take place on an entirely different computing platform. Zim does not have to be connected to the server through the development phase. This “off-line” development capability eliminates the heavy load that can be placed on SQL servers by development activities.
In order to access SQL database tables, Zim must have a definition of the table. The table must be defined in two places: in Zim and in the SQL database. EntitySets and relationships are flagged as being under the control of Zim or under the control of the SQL database. The definitions of those EntitySets and relationships under control of the SQL database are either exported to the SQL database or imported from the SQL database. You must ensure that the definitions in Zim and the SQL database are compatible. Zim’s SQL definition interface provides the means to easily import and export definitions.
Figure 1
In Figure 1, the table “Customers” is defined both in Zim and in the SQL database. If “Customers” is defined as a Zim EntitySet or if Zim is running in ZIM mode, then all references to customers are directed to the Zim EntitySet. If, however, “Customers” is defined to be an SQL table and Zim is running in SQL mode (the default), then all references to customers result in the generation of the appropriate SQL code which is sent to the SQL database.
Zim requires that each EntitySet and data relationship to be managed by the SQL database have at least one unique index defined for it. The unique index is a primary key for the SQL table to which the EntitySet or data relationship corresponds. A primary key is necessary to directly access any record (row) of any SQL table. It does this by generating select statements which specify values for the primary key column(s) of the table. For more information, see Primary Keys.
When developing client-server database applications, it is important to consider the location of the data. Any data under the control of the database server contributes to both the load on the network as well as load on the server machine. Because of this, it is important to analyze the data associated with a given application and determine the best location (or locations).
Static data, or data that does not change, can be duplicated and distributed over the client workstations to reside under Zim control. This type of data is typically part of the application. A table of help screen text messages is an example of static data that can (or should) be located on the client workstation.
Data that changes on a monthly, weekly, or even daily basis can be located on both the client and server workstations. An application can down load this data (or part of it) to a local copy at an appropriate time. The single server copy would be updated as required and client workstations would pick up any updates automatically.
Finally, there is dynamic shared data that resides on the server and is shared by the client workstations. This type of data resides under the SQL database’s control and be accessed and manipulated from within Zim.
English 
Portuguese