Objects, as used in the context of object-oriented programming, are programmatic combinations of data elements and methods. Each data element or method included in an object is either public or private. Public data elements and methods may be manipulated by entities that are external to the object. Private data elements and methods, on the other hand, are encapsulated and may only be manipulated by the object itself. In practice, a typical object includes some number of private data elements and some number of public methods for manipulating the private data elements.
Scalar quantities are objects that are similar to scalar values, such as integer or floating point values. In fact, scalar quantities typically encapsulate a scalar value as a private data element. Unlike scalar values, however, scalar quantities cannot be directly accessed. Instead, scalar quantities provide methods for adding to, or taking away from, the encapsulated scalar value. By restricting access to scalar quantities to these two methods, it becomes possible to provide concurrent access to scalar quantities in a controlled fashion. Simultaneously, it becomes possible to use a technique known as "escrow-locking" to ensure that scalar quantities act as "transaction protected resources."
To understand the role of scalar quantities as transaction protected resources, it is helpful to first understand the transaction abstraction. Fundamentally, a transaction is defined as a unit of work that is 1) "atomic," 2) "consistent," 3) "isolated," and 4) "durable" (more commonly, it is said that transactions have "ACID" properties).
To be "atomic" a transaction must complete in an all-or-none fashion. This means that transaction protected resources must reflect all changes made during a transaction that successfully complete or "commits." It also means that transaction protected resources must reflect none of the changes made during a transaction that fails to commit for any reason.
To be "consistent" a transaction must move transaction protected resources from one consistent state to another. In systems that use the transaction abstraction, consistent states are defined in terms of rules known as integrity constraints. Transactions that violate these integrity constraints are aborted. In this way, transaction protected resources are maintained in consistent states. For example, in a product inventory database, an integrity constraint could be used to abort any transaction that would result in a negative quantity of any product.
To be "isolated" the changes made to transaction protected resources must be invisible to threads and processes that are not associated with the transaction until the transaction has committed. Typically, isolation is achieved by locking the changed resource, forcing threads and processes that attempt to read the locked resource to wait until the transaction has completed.
Finally, to be "durable" the changes made to transaction protected resources must not be lost or corrupted, even in the case of a catastrophic system failure. In this context, durability is not used in the absolute sense. For example, physically destroying the transaction processing computer system and all of its backup records will violate the durability property.
Escrow-locking is the technique that allows scalar quantities to have ACID properties and act as transaction protected resources, without restricting update access to the scalar to a single transaction at a time. For escrow-locking, the scalar value included in a scalar quantity is replaced by a numeric range [m, n]. The numeric range [m, n] of a scalar quantity means that the value of the scalar quantity is between m and n, inclusive. Initially, the numeric range of a scalar quantity is set to be the value of the scalar quantity, i.e., m=n. Thereafter, if the scalar quantity's method for adding to is called to add x to the scalar quantity, the numeric range becomes [m, m+x]. Similarly, if the scalar quantity's method for taking away is called to subtract y from the scalar quantity, the numeric range becomes [m-y, m+x].
Transactions in which the scalar quantity participates are only allowed to commit if the required integrity constraints are valid for the numeric range included in the scalar quantity. In this way, a scalar quantity can participate in multiple concurrent transactions, maintain ACID properties for each transaction, and not cause any transaction to block. This combination of properties make scalar quantities highly useful programming objects. Unfortunately, traditional implementations of scalar quantities have generally been accomplished with less than ideal efficiency. As a result, there are cases where the use of scalar quantities is difficult or even impossible. Thus, a need exists for an efficient scalar quantities implementation that retains the advantages of traditional scalar quantities.
USPTO Backgrounds
USPTO Backgrounds