Different types of auctions are supported, namely English auctions, Dutch auctions, 1st Price auctions, 2nd Price auctions, etc. The English auction is the most well-known form of auction. The item for sale is put up for auction starting at a relatively low minimum price. Bidders are then allowed to place their bids until the auction closes. Sometimes, the duration of the auction is fixed in advance, e.g. 30 days, or, alternatively, a time-out value can be associated with the auction. Each time a new bid is registered, the time-out is reset. The auction closes once the time-out expires.

Maybe the most important requirement for auctions is that they must be fault-tolerant. All-or-nothing semantics must be strictly adhered to. Either there is a winner, and the money has been transferred from the account of the winning bidder to the seller account and the commission has been deposited on the auction system account, or the auction was unsuccessful, in which case the balances of the involved accounts remain untouched.

Auctions are complicated interactions among multiple participants. They incorporate cooperative and competitive concurrency. The participants of an auction cooperate by placing bids on the same item. Members are allowed to participate in several auctions at the same time. Concurrently executing auctions compete for the money on the member accounts.

The number of participants of an auction is not fixed in advance. Therefore, auctions must also be dynamic: new participants must be able to join the auction at any time.

All these requirements can be met if an individual auction is encapsulated inside an open multithreaded transaction. A graphical illustration of an English auction structured as an open multithreaded transaction is shown in the following figure:

Every member creates a new thread that represents the member inside the auction transaction. As a result, members can participate in multiple auctions at the same time.

In the prevous figure, member 1 starts a new auction, creating a new seller thread. A new open multithreaded transaction, here named T1, is started. Then, the seller creates a new Auction object by invoking the Create function, and inserts it into the list of current auctions. Other members consulting the current auction list will now see the new auction. In our example, member 2 decides to participate. A new bidder thread is created, which joins the open multithreaded transaction T1. It queries the amount of the current bid by invoking the Get_Current_Bid operation on the auction object. Before placing the bid, a new subtransaction, here named T1.1, is started. Within the subtransaction, the required amount of money is withdrawn from the account of member 2. Since there is enough money on the account, the withdrawal completes successfully and the bid is announced to the Auction object by calling Place_Bid.

In the meantime, some other member, member 3, joins the auction, spawning also a bidder thread, which joins the open multithreaded transaction T1. After consulting the current bid, member 3 decides to overbid member 2. Again, a subtransaction is started, here named T1.2, and the required amount of money is withdrawn from the account of member 3. The new bid is announced to the Auction object by calling Place_Bid. Once the bidder thread of member 2 gets to know this, it consequently aborts the subtransction T1.1, which in turn rolls back the withdrawal performed on the account of member 2. The money returned to the account of member 2 can now be used again for placing new bids.

In the example no other bidders enter the auction, nor does member 2 try to overbid member 3. The bidder thread of member 2 has therefore completed its work inside the auction, and commits the global transaction T1. Once the auction closes, the bidder thread of member 3 gets to know that it has won the auction. It then commits the subtransaction T1.2, which confirms the previous withdrawal. It also commits the global transaction T1. The seller thread in the meantime deposits two percent of the amount of the final bid on the account of the auction system as a commission, deposits 98% of the amount of the final bid on the account of member 1, inserts the Auction object into the history of the Member_Information object of member 1, and finally also commits T1.

Only now that all participants have voted commit, the transaction support will make the changes made on behalf of T1 persistent, i.e. the creation of the auction object, the bidding, the withdrawal from the account of member 3 (inherited from subtransaction T1.2), the deposit on the auction system account, the deposit on the account of member 1, and the insertion of the auction object into the history of the Member_Information object of member 1.

Using open multithreaded transactions in the design of the auction system has greatly simplified the problems introduced by the inherent concurrency and dynamicity of the system. The application state remains consistent in spite of concurrent auctions. Executing an individual auction inside a transaction automatically provides the desired all-or-nothing semantics: either the auction completes as a whole, or no money is transferred between accounts. Fault tolerance is also provided automatically by the underlying transaction support.

Inside an auction, partial undo functionality has been achieved using nested transactions. When a user places a bid, the money is withdrawn from his account inside a nested transaction. Later on, if someone places a higher bid, the money is returned to the account by aborting the nested transaction. That way, a user that participates in several auctions concurrently can not cheat and overdraw his account.

Click here to download the auction system example. It has been developped and tested under GNAT 3.13p, and GLADE 3.13p (the GNAT implementation of the Distributed Systems Annex). The user interface has been implemented using Gtk-Ada, so be sure to have GLADE and Gtk-Ada installed before compiling the auction system example. (It seems to be quite tricky to get GLADE and Gtk-Ada to work together. It took our system administrator quite some time. The problem is that GLADE modifies some files of GNAT, so be sure that you use these new files when you compile Gtk-Ada.)

Last modified: November 23, 2015, Jörg Kienzle