Reply to Thread

Message:: [QUOTE="kirispupis, post: 8233544, member: 118780"]My suspicion is the system tracks pre-bids vs live bids in separate tables. This makes sense since the pre-bids generate far less performance/concurrency concerns than the live portion. When you update your pre-bid, it just increases your current pre-bid while keeping the timestamp (which may be necessary when resolving conflicts). During the live stage, each bid is entered into another table. It's then possible to read the bids with the appropriate data concurrency model without a transaction, or if this is some in-memory data structure, a short read-lock. This maximizes the performance. The ability to view bidding history was obviously added after this system was created. Since not all bidding records were necessary to compute the highest bidder, the programmer was only able to output the existing rows. Therefore, my previous "automatic" bid of 550 is not listed because it occurred during the pre-bid portion, and the system was able to calculate the maximum bid easily given the current table contents. There's no need for a separate row except for data reporting, which as I mentioned was clearly added afterwards. However, the live portion does require a more robust system requiring that two-step process, and therefore each bid has its own row that shows in the summary. There's no bug here other than lazy programming.[/QUOTE]