3 ms·

thanks mseebach, I don't think your concept will work (and I've been known to be wrong before) ... but at least I understand how you're approaching the problem,

by owkaye 18y ago

thanks mseebach, I don't think your concept will work (and I've been known to be wrong before) ... but at least I understand how you're approaching the problem, and that helps me to get a better grasp of how I might have to go about it. It seems to me that I'll have the fastest performance by storing all the bid values in a single 'column' (in RAM of course) to make it faster to find a new unique high bid when someone posts a bid that matches the existing unique high bid. So here's my current concept of how to structure the RAM data: Create a RAM-based 'table' with only two 'columns', bidValue and bidStatus. The bidStatus column will store a single character such as 'D' for a duplicate bid, or 'U' for a unique bid, or 'H' for the unique high bid. Then go through this procedure when someone posts a new bid: - See if his bid matches the 'H' bidValue: - If so, change the bidStatus from 'H' to 'D' then identify the new unique high bid and change that bidStatus from 'U' to 'H'. - If not, and if there is already a matching bidValue in the table, set that bidStatus to 'D' - If not, and if there's no matching bidValue in the table, append a new row, then: ---------- If the bidValue in the new row is lower than the one in the 'H' row, set the bidStatus to 'U' ---------- If the bidValue in the new row is higher than the one in the 'H' row, set the bidStatus to 'H and change the old 'H' status to 'U' - Append the new bidValue, timeStamp and bidderID to another RAM-based table designed to store this data for each bidder (to create an archive of the auction). -- Send the status of the member's new bid back to him so he will see it in his browser.

mseebach 18y ago
The exercise is to make your critical region (ie. the section of code that only ONE client can be executing at the same time) as small as possible, since it will be the limiting factor. If you don't think my solution will work, please explain, in terms of business requirements, why it won't - because I can't see what your alternative solution achieves, except being orders of magnitude slower then mine. For an example, you want to search for the current highest bidder. Why not always keep the current highest bidder in the same place? Looking in one place costs 1 cycle, looking in thousands of places (searching) costs thousands of cycles. Write me an email (see my profile) if you want to continue the discussion. You can NDA me if you want to.
- whatusername 18y ago
  You probably should listen to this advice. (Searching through every bid is going to be painful). The highest unique bid complicates things slightly.. All of your bids have 3 possibilities compared to the current highest bid. (lower, same, higher). LOWER: lower is easy - it's not a winner. Except for this scenario: 1. $10 --> Becomes highest unique 2. $9 --> lower, not a winner 3. $10 --> Duplicate with no.1 no.2 ($9) is now highest unique SAME: Same is easy - your old highest unique no longer is a win. HIGHER Higher becomes a win - UNLESS there's already 2 (or more) bids at that value. Some thoughts - perhaps store three lists and a value? sorted list of duplicates lower than the Highest Unique Value (HUV) sorted list of duplicates higher than the HUV sorted list of uniques Current HUV Take a new bid. Compare to the HUV: Lower: not a winner. SAME: not a winner - HUV updated to next highest unique. value appended to duplicates list. HIGHER: compare to Higher duplicates list. If not in there - update as HUV - winner. Behind the scenes - I assume you're logging each bid, details, etc.. You wouldn't have to wait to do this in order to return a result. Is that understanding your issue?
  - owkaye 18y ago
    Thanks for the HUV acronym whatusername, it makes describing things easier. I think you have a pretty good understanding of the system now. I'll reword your description in an effort to clarify, and if this is not the way you understand it please tell me so I can try to make a better explanation. Every bid has 3 possibilities compared to the current HUV: lower, same, higher. LOWER = not a winner simply because it's lower SAME = not a winner because it's a duplicate HIGHER = additional checking required: HIGHER and DUPLICATE = not a winner HIGHER and UNIQUE = winner! That's basically how to determine the status of a new bid. As far as programming tasks are concerned, the value of each new bid must be added to the list of existing bids if it's not already there. Then the status of the new bid must be updated ... and if this changes the status of the HUV, the new HUV must be determined: Determining a new HUV is where sorting becomes necessary, but I think this may be the ONLY place where a sort is required. >>> Behind the scenes - I assume you're logging each bid, details, etc.. You wouldn't have to wait to do this in order to return a result. <<< Yes, logging each bid is important but previously I failed to 'separate' the logging task from the process described above. If the HTTP server can log the cookie value (bidderID) and the post data (bidValue) itself that's all I may need. On the other hand this assumes a new connection to the HTTP server every time a bid is posted -- and if I use Ajax to pass data back and forth without creating these new connections I will also need a separate app to take care of the logging.

by owkaye 18y ago

mseebach 18y ago

The exercise is to make your critical region (ie. the section of code that only ONE client can be executing at the same time) as small as possible, since it will be the limiting factor. If you don't think my solution will work, please explain, in terms of business requirements, why it won't - because I can't see what your alternative solution achieves, except being orders of magnitude slower then mine. For an example, you want to search for the current highest bidder. Why not always keep the current highest bidder in the same place? Looking in one place costs 1 cycle, looking in thousands of places (searching) costs thousands of cycles. Write me an email (see my profile) if you want to continue the discussion. You can NDA me if you want to.

whatusername 18y ago
You probably should listen to this advice. (Searching through every bid is going to be painful). The highest unique bid complicates things slightly.. All of your bids have 3 possibilities compared to the current highest bid. (lower, same, higher). LOWER: lower is easy - it's not a winner. Except for this scenario: 1. $10 --> Becomes highest unique 2. $9 --> lower, not a winner 3. $10 --> Duplicate with no.1 no.2 ($9) is now highest unique SAME: Same is easy - your old highest unique no longer is a win. HIGHER Higher becomes a win - UNLESS there's already 2 (or more) bids at that value. Some thoughts - perhaps store three lists and a value? sorted list of duplicates lower than the Highest Unique Value (HUV) sorted list of duplicates higher than the HUV sorted list of uniques Current HUV Take a new bid. Compare to the HUV: Lower: not a winner. SAME: not a winner - HUV updated to next highest unique. value appended to duplicates list. HIGHER: compare to Higher duplicates list. If not in there - update as HUV - winner. Behind the scenes - I assume you're logging each bid, details, etc.. You wouldn't have to wait to do this in order to return a result. Is that understanding your issue?
- owkaye 18y ago
  Thanks for the HUV acronym whatusername, it makes describing things easier. I think you have a pretty good understanding of the system now. I'll reword your description in an effort to clarify, and if this is not the way you understand it please tell me so I can try to make a better explanation. Every bid has 3 possibilities compared to the current HUV: lower, same, higher. LOWER = not a winner simply because it's lower SAME = not a winner because it's a duplicate HIGHER = additional checking required: HIGHER and DUPLICATE = not a winner HIGHER and UNIQUE = winner! That's basically how to determine the status of a new bid. As far as programming tasks are concerned, the value of each new bid must be added to the list of existing bids if it's not already there. Then the status of the new bid must be updated ... and if this changes the status of the HUV, the new HUV must be determined: Determining a new HUV is where sorting becomes necessary, but I think this may be the ONLY place where a sort is required. >>> Behind the scenes - I assume you're logging each bid, details, etc.. You wouldn't have to wait to do this in order to return a result. <<< Yes, logging each bid is important but previously I failed to 'separate' the logging task from the process described above. If the HTTP server can log the cookie value (bidderID) and the post data (bidValue) itself that's all I may need. On the other hand this assumes a new connection to the HTTP server every time a bid is posted -- and if I use Ajax to pass data back and forth without creating these new connections I will also need a separate app to take care of the logging.