On Wed, 2010-03-17 at 13:29 +0200, Alexander Georgiev wrote:
> 2010/3/17 Neil Aggarwal <neil@xxxxxxxxxxxxxxxxxx>:
>
> > 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
