The Multiuser Tab

Restriction: This topic applies to Windows environments only.

The Multiuser tab allows you to specify options relating to the use of a multiuser, XDB Server in a networked environment.

Isolation Level	XDB Server provides six levels of isolation so users can control the tradeoff between concurrency and consistency: `Concurrency` is the ability for multiple transactions to access database resources simultaneously. `Consistency` is the degree to which changes made by one user have no negative effects on other transactions in a multiuser environment. Within the maximum degree of consistency and minimum degree of concurrency, the isolation levels are:
	Exclusive Use	The entire database is locked for exclusive use of the current transaction.
	Repeatable Read	All locks are held until commit point to guarantee that transactions can be done serially.
	Cursor Stability	Exclusive (read-write) locks are held until commit, and shared (read-only) locks are released when the next record is accessed.
	Lock Current	Only the current record is locked. This level should be used with AUTOCOMMIT ON, or for read-only operations.
	Dirty Read	No locks are obtained. Uncommitted record changes are read regardless of locks (other than database locks). A DR transaction is read-only; records cannot be modified.
	Snapshot Read	At this level, a snapshot of the data is made at the time of execution. Other users can make changes to the data without waiting for the transaction to complete and the user is ensured that the data will be the same for the life of the transaction. An SR transaction is read-only
Time-out Interval	This is the length of time (in seconds) to wait before retrying, when a lock conflict occurs.
AutoCommit	With AUTOCOMMIT on, an SQL command is committed as soon as it is successfully completed. If AUTOCOMMIT is off, the user needs to explicitly commit transactions by issuing an SQL COMMIT command or by selecting COMMIT from a menu in an application. AUTOCOMMIT is not supported against XDB Link locations.
Backward Logging	This option is used only when accessing XDB Server Versions 3.`x` and 4.`x`. If using XDB Server Version 5.0 or higher, logging is automatic and this option is ignored. To perform a rollback operation when using the older XDB Server versions, it is necessary to maintain a log of `before images` of all changes made to the database during a transaction. This information is stored in a `backward log`. The backward log contains only the information necessary to roll back the current transaction. Every time a transaction is committed or rolled back, the backward log is erased. When the log is turned off, rollback is not possible, but changes to the database take less time because `before images` are not written to the log. For more about backward logging on the older XDB Server versions, see the Backup and Recover chapter of the XDB Server Administration Guide for the XDB Server version you are using.