Transaction in AvisMap GIS Engine
Short transaction and Long transaction are all supported in AvisMap GIS Engine.
What’s transaction?
Transaction is a common conception in database applications, which is a series of operations being performed based on a single logistic work cell. There are four properties to each logistic work cell, called ACID (Atomicity, Consistency, Isolation and Durability) which are absolutely necessary to a transaction. Among these properties, the concurrency and atomy are the key points needed to be concerned especially in GIS applications. Where, concurrency can control a GIS data can not be modified by two or more users simultaneously or one user can not edit the data before the other ones has committed the updates; and atomicity can insure that all work flows in a transaction can be treated and finished just as an integrated group. If there is one step failed, the other should stop to be continued. This kind of mechanism of transaction is provided by database management system (DBMS), and surely supported by AvisMap GIS Engine, that is short transaction mechanism.
Limitations of short transaction:
- As short as possible.
- Users other than the one who is editing a GIS dataset can not edit even browse the dataset.
- Transaction can not span long period of time; it must be committed or rolled back before you shut down your computer at least.
- If there are some unexpected circumstances occurring, for example, power interruption or computer down, the changes will be lost.
Long transaction in AvisMap GIS Engine:
GIS users have some specialized transactional requirements:
- Transactions must span long periods of time, sometimes days and months, not just seconds or minuets.
- Once modifications have been done, it would not lost even some unexpected circumstances mentioned above have taken place.
- Users can roll back all changes at any time if they are not satisfied with them.
- Any changes being committed can be seen by other users.
- The other users can modify the area previously locked by one user only after it has been committed or rolled back.
The long transactions in AvisMap GIS Engine SDM can completely meet the above requirements. The comparisons between the short and long transactions in AvisMap GIS Engine SDM are listed as below:
| Characteristics | Long Transactions | Short Transactions |
|---|---|---|
| Multiuser editing | Yes | No |
| Time | Long (days, months or longer) | Short |
| Unexpected circumstances occurring | Changes will be kept | Changes will be lost |
How to use long transaction in AvisMap GIS Engine SDM?
It is very easily to use the long transaction functions of SDM datasource, the soLongTransaction object is provided to perform the operations of long transaction. We can get the object through the following code (here, take the VB code as example):
Dim objLT As soLongTransaction
Set objLT = objDatasource.LongTransaction ……
Operations in long transaction:
There are three basic operations in long transaction object: CheckOut, CheckIn and UndoCheckOut.
CheckOut: Identify the transaction has started and lock the data required to be edited until the transaction terminated, and during the period other users can only view and get the state of the data before it has been checked out.
CheckIn: Commit all changes modified by user, and determine whether the data will be continued checked out which is set according to the parameter involved in the method. After calling the method, other users can view the newest data.
UndoCheckOut: Once you undo all changes, the data will be rolled back to its original state. If the property AutoCheckOut of soLongTransaction object has been set as False, the locked data will be released otherwise locked continuously.
Operable data level:
The long transaction can be done on three data levels: DataSource, Dataset and Recordset.
DataSource: Perform transactions in dataSource in which all data except for those locked by other users will be checked out.
Dataset: Perform transactions in dataset (layer or table) in which all data except for those locked by other users will be checked out.
Recordset: Perform transactions in recordset in which all records that meet the condition or a certain area in layer will be checked out.
Descriptions of Properties and Methods:
All the properties and methods listed below are involved in the object soLongTransaction:
| Properties | Type | Description |
|---|---|---|
| User | BSTR | User name logged in long transaction. |
| Password | BSTR | Long transactional user’s password |
| Logged | Boolean | Identifies whether a user has successfully logged in long transaction environment. |
| AutoCheckOut | Boolean | Identifies whether the state of CheckOut will be kept continuously after committing or rolling back the changes. |
| Methods | Data Level | Description |
|---|---|---|
| LogIn | - | Logs in long transaction. |
| LogOut | - | Logs out long transaction. |
| CheckOut | DataSource | Checks out or locks the datasource to begin transaction process. |
| CheckIn | DataSource | Checks in or commits the changes to datasource. |
| UndoCheckOut | DataSource | Undoes or rolls back the changes to datasource. |
| CheckOutDataset | Dataset | Checks out or locks the specified dataset (table or layer). |
| CheckInDataset | Dataset | Checks in or commits the changes to dataset (table or layer). |
| UndoCheckOutDataset | Dataset | Undoes or rolls back the changes to dataset (table or layer). |
| CheckOutRecordset | Recordset | Checks out or locks a certain recordset (or an area of a layer). |
| CheckInRecordset | Recordset | Checks in or commits the changes to recordset. |
| UndoCheckOutRecordset | Recordset | Undoes or rolls back the changes to recordset. |
Tips:
- Long transaction is available in SDM for Oracle and SDM for SQL Server.
- Long transaction user should be created in server side by DBA before you log in the environment. For example, if you have installed the Oracle client software, open Oracle Enterprise Manager Console, click Database and expand solutions, select a certain instance and find SMLTUSERS table, right-click Browse/Edit Directory…, you can add users and set passwords for them in this table, or use SQL statements directly.
- If you have logged on long transaction environment, but have not set the property AutoCheckOut as True, the data could not been edited.
- The data definition language for instances creating or deleting table, creating or deleting field etc will do the really changes to database and can not be rolled back in long transaction, therefore, you should check in or undo your changes before performing any DDLs.