On Wed, 2010-03-17 at 13:29 +0200, Alexander Georgiev wrote: > 2010/3/17 Neil Aggarwal <neil at jammconsulting.com>: > > > The only potential place a conflict may occur is in > > the qty available for a specific product. The inventory > > system updates the inventory regularly so even if the number > > is wrong, it gets refreshed shortly thereafter. > > > > Do you mean that a separate job, iterates the orders, accumulates the > real ordered quantity and subtracts it from some "initial quantity" in > order to produce available quantity? > > What do you do in cases where you have oversold a product. I mean when > the "ordered quantity" got bigger than the "available quantity" due > to a conflict in available quantity field? I assume that the system > sends an email to the warehouse to increase additionally the quantity > of that product? > > > We even built an application layer on top of master-master > > replication to handle cases where a transaction fails. > > > > Could you describe a case where a transaction has failed , and how you > deal with it? Yes im interested to hear that also because im not aware that MySQL has any type of feature like: database.rollback() or table and collumn rollback on a bad transaction. I have always heard the replication of MySQL could not keep up with lots of writes. Have you thought of separating the databases? One for the reads and one for the write on different raids? Despite what some may believe this can be done. John