Locking

A user can use locking to gain update control of an object in the data store to the exclusion of other users. There are two general types of locks - transaction locks and persistent locks. Transaction locks are temporary and endure only for the duration of the transaction. Persistent locks applied to objects by a user remain with the object until either that user removes those locks or the locks are removed by another user with the appropriate authority. Following locking types are available:

• All long transaction exclusive - indicates that only this user can modify this object in this long transaction. No user, not even the user locking the object, can modify the object in any long transaction created as a descendant of the one containing the object being locked. When not in a long transaction situation (for example, if only a root long transaction exists), the lock behaves like an Exclusive lock.
• Exclusive - indicates that only this user can modify this object. In a long transaction situation, any user can modify the object in any other long transaction, including the root long transaction if it is not the current long transaction.
• Long transaction exclusive - indicates that only this user can modify this object in the long transaction containing the object or any long transaction created as a descendant of that one. When not in a long transaction situation (for example, if only a root long transaction exists), the lock behaves like an Exclusive lock.
• Shared - indicates a shared lock type.
• Transaction - indicates that a transaction lock should be applied to an object.

Transactions

A transaction changes the data store in some way. The way these changes affect the data store is determined by the transaction's properties. For example, the Atomic property specifies that either all changes happen or non happen. In transaction processing the data store treats a series of commands as a single atomic unit of change to that data store. Either all changes generated by the commands are successful or the whole set is canceled. A transaction is a single atomic unit of changes to a data store. The application terminates a transaction with either a commit, which applies the set of changes, or a rollback which cancels the set of changes. Further, the data store may automatically roll back a transaction if it detects a severe error in any of the commands within the transaction. A transaction has the following properties:

• Atomic - either all changes generated by the commands within a transaction happen or none happen.
• Consistent - the transaction leaves the data store in a consistent state regarding any constraints or other data integrity rules.
• Isolated - changes being made within a transaction by one user are not visible to other users until after that transaction is committed.
• Durable - after a transaction is completed successfully, the changes are persistent in the data store on disk and cannot be lost if the program or processor fails.

Long Transactions

A long transaction (LT) is an administration unit used to group conditional changes to objects. Depending on the situation, such a unit might contain conditional changes to one or to many objects. Long transactions are used to modify as-built data in the database without permanently changing the as-built data. Long transactions can be used to apply revisions or alternates to an object.

A root long transaction is a long transaction that represents permanent data and that has descendants. Any long transaction has a root long transaction as an ancestor in its long transaction dependency graph. A leaf long transaction does not have descendants.

Threading

• Per connection threaded - indicates that the provider supports a single thread per connection. Multiple concurrent threads cannot access the same connection object and only one command can be executing per connection. Multiple connections can be active concurrently as long as each is executing on its own thread.
• Per command threaded - indicates that the provider supports a single thread per command. Multiple concurrent threads cannot access the same command object; however, multiple commands can be executing concurrently against a single connection.
• Single threaded - indicates that the provider is not thread safe.

Other Connection Capabilities

• Configuration - indicates whether or not a provider can specify on a closed connection an XML source to be used to configure the data store.
• Flush - indicates whether or not a provider supports the forced write of cached data associated with a connection to the target data store.