5 ms·

Just to make it clear, the issue the OP is pointing out is with whoever wrote this inexcusable piece of code in the book, not MongoDB itself. Even if the author

Just to make it clear, the issue the OP is pointing out is with whoever wrote this inexcusable piece of code in the book, not MongoDB itself. Even if the authors later clarify there's the possibility of error, just publishing such misleading and grotesque solution for creating transactions in a non ACID database is very poor judgement. MongoDB should not be used for an online ordering system, period. But if the programmer had no better alternative than Mongo, then please use Mongo's atomic operations [1] and nested documents to make sure nasty Bad Things don't happen. [1] https://docs.mongodb.com/manual/tutorial/model-data-for-atomic-operations/ https://docs.mongodb.com/manual/tutorial/model-data-for-atom...

tyingq 9y ago
In the case of an ecommerce site, where multiple products can go in a cart, I don't see any real right way to do things with MongoDB. Atomic for one row just doesn't help much, and you can't nest arbitrary cart product mixes. As you say, bad idea in the first place.
- electricEmu 9y ago
  I was part of a team that successfully did inventory in mongo. The cart makes zero difference if Mongo is only storing the inventory. It's fine to atomically change a single inventory row. Operations that span multiple rows can be safely performed with a bus in front of it. You can't judge the idea. I don't think you've quite grasped it. I agree the book example isn't great, but that's not the technology's fault.
  - tyingq 9y ago
    I am assuming a system where available inventory is debited when the CC transaction completes. How do you do that with single row only atomic transactions? And without charging $100 for what the customer thought was qty 3 $25 rakes and qty 1 $25 shovel...but is now something less than that due to concurrent purchases from other customers?
    - ryanworl 9y ago
      And what happens when that shovel gets stolen from the warehouse before it can be shipped to the customer? You have to handle over-selling no matter what. The "source-of-truth" of you inventory system is whatever is actually, physically sitting in a warehouse somewhere. Not what your database says.
      - MichaelGG 9y ago
        I think Amazon calls it Apology Based Computing or something like that. You're better off at scale writing out a transaction log, then seeing if actions were successful and compensating otherwise.
      - tyingq 9y ago
        Yes, you have to handle overselling for other reasons, but I don't see why that's a good reason to not protect against it when you can.
    - DannyBee 9y ago
      "How do you do that with single row only atomic transactions?" In this scheme, you should theoretically be able to implement transactional protocols (two phase commit and friends, see, e.g., http://dl.acm.org/citation.cfm?id=3027893 http://dl.acm.org/citation.cfm?id=3027893) that ensure you do not actually sell two people the same thing, but may return an error at buy time that the inventory disappeared while you tried to buy it. You pay a sometimes-very-high cost in throughput. Of course, talking about mongodb, it's probably broken in a myriad of ways no matter what you do :)
      - electricEmu 9y ago
        Nailed it, but I'm curious where you think the throughout suffered; we didn't encounter that problem.
    - electricEmu 9y ago
      It was a distributed system. The inventory was kept in Mongo with atomic debits and credits applied with a bus in front. SQL existed for the actual order, but inventory was managed in Mongo fine. I'd like two of this product? Increment reserved in Mongo atomically, fire a bus message that inventory was reserved. I'd now like just one? Again atomically remove one from reserved and fire another message. Simplified of course. Two users can't reserve the same inventory, reserving the inventory is atomic, and everyone else occurs during reconciliation. Typical distributed systems.
  - elmigranto 9y ago
    > I was part of a team that successfully did inventory in mongo. Yes, sure, let's go all get PHDs in electronics, networking protocols, IPC and database architecture, so we can write reliable transactions for our webshop/CRM. Or I don't know, maybe use mature system multiple decades in production.

tyingq 9y ago

In the case of an ecommerce site, where multiple products can go in a cart, I don't see any real right way to do things with MongoDB. Atomic for one row just doesn't help much, and you can't nest arbitrary cart product mixes. As you say, bad idea in the first place.

electricEmu 9y ago
I was part of a team that successfully did inventory in mongo. The cart makes zero difference if Mongo is only storing the inventory. It's fine to atomically change a single inventory row. Operations that span multiple rows can be safely performed with a bus in front of it. You can't judge the idea. I don't think you've quite grasped it. I agree the book example isn't great, but that's not the technology's fault.
- tyingq 9y ago
  I am assuming a system where available inventory is debited when the CC transaction completes. How do you do that with single row only atomic transactions? And without charging $100 for what the customer thought was qty 3 $25 rakes and qty 1 $25 shovel...but is now something less than that due to concurrent purchases from other customers?
  - ryanworl 9y ago
    And what happens when that shovel gets stolen from the warehouse before it can be shipped to the customer? You have to handle over-selling no matter what. The "source-of-truth" of you inventory system is whatever is actually, physically sitting in a warehouse somewhere. Not what your database says.
    - MichaelGG 9y ago
      I think Amazon calls it Apology Based Computing or something like that. You're better off at scale writing out a transaction log, then seeing if actions were successful and compensating otherwise.
    - tyingq 9y ago
      Yes, you have to handle overselling for other reasons, but I don't see why that's a good reason to not protect against it when you can.
  - DannyBee 9y ago
    "How do you do that with single row only atomic transactions?" In this scheme, you should theoretically be able to implement transactional protocols (two phase commit and friends, see, e.g., http://dl.acm.org/citation.cfm?id=3027893 http://dl.acm.org/citation.cfm?id=3027893) that ensure you do not actually sell two people the same thing, but may return an error at buy time that the inventory disappeared while you tried to buy it. You pay a sometimes-very-high cost in throughput. Of course, talking about mongodb, it's probably broken in a myriad of ways no matter what you do :)
    - electricEmu 9y ago
      Nailed it, but I'm curious where you think the throughout suffered; we didn't encounter that problem.
  - electricEmu 9y ago
    It was a distributed system. The inventory was kept in Mongo with atomic debits and credits applied with a bus in front. SQL existed for the actual order, but inventory was managed in Mongo fine. I'd like two of this product? Increment reserved in Mongo atomically, fire a bus message that inventory was reserved. I'd now like just one? Again atomically remove one from reserved and fire another message. Simplified of course. Two users can't reserve the same inventory, reserving the inventory is atomic, and everyone else occurs during reconciliation. Typical distributed systems.
- elmigranto 9y ago
  > I was part of a team that successfully did inventory in mongo. Yes, sure, let's go all get PHDs in electronics, networking protocols, IPC and database architecture, so we can write reliable transactions for our webshop/CRM. Or I don't know, maybe use mature system multiple decades in production.