[Rails] HTTP Streaming: Javascript in the head or at the bottom of the page?
There's a discussion going on at StackOverflow about whether, with the advent of HTTP streaming in Rails 3.1, it's time to bend the rules with respect to the time honoured tradition of putting
[Rails] Re: Controlling concurrency
@Fred: The information that only n more products exist will come from (@product.order_limit - @product.orders.count) >= n. It's a bit more complicated than that, because I plan to have optional per- ProductVariant limits too, but let's leave it there for now. @Fred & @Hassan: I don't really want to have "unsold" ProductVariants hanging around in the database, because the availability of ProductVariants is largely procedural. If the order_limit on the Product as a whole was 20, the order_limit on ProductVariant A was 10, and ProductVariant B had no order_limit, then I'd end up with a whole lot of questions as to how many unsold ProductVariants to create of each type, and which ones to destroy when others were sold. Bah, too much mess! @Charles: I like the idea of an OrderTaker global queue, but global queue means worker process, and worker process means extra messy infrastructure, right? I'm all for it, I'm just wondering if anyone has a better mousetrap. @Fred: Row-level locks are out of the question, since I'm not interested in blocking updates to a given row, but the creation of rows that don't yet exist in the Orders table. That said, I found this today – named locks in MySQL. It's a database-specific solution, but perhaps an easy one? http://gist.github.com/95977 Named locks in MySQL: http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_get-lock Shopify's locking implementation: http://github.com/Shopify/locking/blob/835469ed48f4c2de95856fe2f221eaa624b267a2/lib/locking.rb --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Rails] Controlling concurrency
What do you think is the best way to manage concurrency in this (made up) scenario? 1) You are selling Orders for items of various ProductVariants, belonging to one Product 2) There may be an upper limit to how many Orders you can take for any given Product 3) For our example today, you can only accept three more orders for any combination of ProductVariants of a Product 4) Two users put in three Orders, at the same time It's in the realm of millisecond possibility, then, for this to happen: Person 1: Validate that 3 Orders can be made for Product 123 => true Person 2: Validate that 3 Orders can be made for Product 123 => true Person 1: Orders.create(:product_variant => 9); Orders.create (:product_variant => 8); Orders.create(:product_variant => 7) Person 2: Orders.create(:product_variant => 6); Orders.create (:product_variant => 5); Orders.create(:product_variant => 4) Oops! 6 Orders placed! 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? 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 -~--~~~~--~~--~--~---
