On Apr 15, 3:28 pm, Charles Johnson <gm.johns...@gmail.com> wrote:
> If you positively cannot have overbooking (oops, airline talk) over-selling,
> then all your orders have to either lock a table (using the database to
> enforce serialization)
I don't think things have to be quite so drastic, eg a row level lock
is almost certainly enough. It does sort of depend on how the quantity
information is stored (but there is almost always a better way than a
table lock)
Fred
, or they have to be serially examined in someway,
> such as a single order FIFO queue. You could create an observer, for
> example, that monitors the creation of an order, checks to see if stock
> (tickets, seats, CD's, whatever) is available; and gracefully back-out an
> order that "goes over." Personally, I would be tempted to try a simple
> solution, like a queue of some sort first, or perhaps an observer, rather
> than use the database. This is one of those cases where trying to optimize
> too early may hurt. A simple, single, global queue may be all you need.
> YMMV.
> Cheers--
>
> Charles
>
> On Wed, Apr 15, 2009 at 3:02 AM, Frederick Cheung <
>
> frederick.che...@gmail.com> wrote:
>
> > On Apr 14, 10:55 pm, steveluscher <goo...@steveluscher.com> wrote:
> > > What do you think is the best way to prevent overselling in this case?
> > > I've considered:
>
> > > * Table locking (sucks)
> > > * Setting a lock file per-Product (filesystem-y and not elegantly
> > > scalable past one machine)
> > > * Setting a lock variable per-Product in a memcached store
> > > * A single-worker queue that validates and processes orders in
> > > sequence
> > > * A per Product single-worker queue that validates and processes
> > > orders in sequence
> > > * Something I haven't considered?
>
> > It sort of depends where the information that only 3 more orders for
> > Product X lives.
> > For example if the products table has a stock_remaining column, then
> > for me the natural thing to do would be to use optimistic locking on
> > the products table
> > I wrote up some possibilities at
> >http://www.spacevatican.org/2008/6/8/dealing-with-concurrency
>
> > Fred
> > > What do you think?
> > > Steve!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
