![](bg4.png)
Though ACID-properties are suitable for traditional
short lasting transactions (
Gray & Reuter, 1993) they
would overly restrict the performance of long lasting
activities such as Combinatorial business
transactions. On the hand, it is well know that by
using semantic information of specific transaction
types it is possible to weaken the ACID-properties
(Lynch, 1987; Garcia-Molina, 1987; Daconta et al.,
2003). For example, with Combinatorial business
transactions the requirements of execution atomicity
and failure atomicity significantly deviates from
traditional database transactions. These issues are
considered in the following Sections 4.1 and 4.2.
4.1 Ensuring the Execution Atomicity
of Combinatorial Business
Transactions
A natural and sufficient criterion for transaction
isolation correctness (execution atomicity) is that the
executions of transactions are serializable, i.e.,
equivalent to a serial execution
(Bernstein &
Newcomer, 1997). This criterion is also intuitive and
clear. However, though it is suitable for traditional
transactions it would overly restrict the concurrency
of long lasting activities such as Combinatorial
business transactions.
Within Combinatorial business transactions
concurrency control is only required to ensure that
concurrent Combinatorial transactions will not
interfere with each others. That is, if the marketplace
has informed the availability of certain products, and
if the buyer certifies the request, then the seller must
still be able to realize the purchase.
In order to illustrate this let us assume that a
seller has placed for sale120 units of product P.
Then buyer A makes a request including 100 units of
product P, and the marketplace sends the availability
message to the buyer A. Then buyer B makes a
request including 40 units of product P, and buyer C
makes a request including 10 units of product P.
What should the marketplace do?
The marketplace should now send the
availability message (i.e., message in-forming that
the 10 units of product P is available) to the buyer
requesting 10 units of product P, but not with the
buyer requesting 40 units of product P. Otherwise, if
the buyers A and B would certify their requests on
product P, then the marketplace does not have
enough units of product P to deliver to both A and
B, i.e., the execution atomicity would not be
preserved. And so other concurrent activities
jeopardized the execution atomicity of
Combinatorial business transactions.
The actual problem here is that how correct
actions can be determined automatically. If the
execution is ensured by traditional data item locks,
then the data item indicating the amount of
requested products is locked in the marketplace
before sending the availability-message to the buyer,
and the lock is not released until the certification
from the buyer is received. However, as the time for
waiting the certification may be arbitrary long this
kind of solution is not acceptable. Instead, according
to our approach the execution of the Combinatorial
business transactions is divided into two transactions
(Figure 2).
Figure 2: The structure of a Combinatorial business
transaction.
• The first transaction, called reservation
transaction, is executed after the
availability of the products is checked and
before the availability-message is sent to a
buyer. It ensures (e.g., by making a
preliminary reservation on the products)
that the products that are available will also
be available until the certification-message
has been received, i.e., other concurrent
activities cannot reserve or sell the product.
• The second transaction, called certification
transaction, is executed after the
marketplace has received the certification-
message. It has two functions: it marks the
products sold that the buyer certified (if
any) and it cancels the reservations of the
products that the buyer did not certified (if
any).
Note that, the reservation transaction and the
certification transactions are traditional database
transactions, i.e., they are so called ACID-
transactions, which either commit or abort. Also
note that the reservation transaction ensures that the
certification transaction cannot semantically fail. By
a semantic failure we mean a case where a product
cannot be sold as it is no more available. So within
the Combinatorial transaction the reservation
transaction behaves like the write–lock of a
WEBIST 2008 - International Conference on Web Information Systems and Technologies
480