Hi Ben, On Fri, Aug 21, 2009 at 4:38 PM, Ben Short<[email protected]> wrote: > Is this a plausible solution to handling stock control? > > 1. A user adds a product to his shopping cart. > 2. The user then clicks on the check out link. This creates an order in the > repos /content/webshop/customer/orders/unique_order_name with a property > called state set to new. > 3. The user then gets a wait page that keeps > polling /content/webshop/customer/orders/new/unique_order_name until state > changes to assigned or error. > 4. When the state has changed the user sees an appropriate page....
Sounds good. For security, you might need to either make unique_order_name non-guessable (if that's good enough), or set access rights on the order node so that only the owner can see it. >... After step 2 a observer (maybe a job is better suited) is fired that > performs the stock allocation and updates the order state. The job or > observer would need to only process one order at a time to make sure that > the stock levels are updated correctly.... Having a single thread that processes those allocations sequentially, triggered by observation of the temporary orders, sounds to me like a good way to solve your problem. In theory, you could be careful about how you process your requests and play with the JCR session's transient space to manage concurrency without resorting to this, but a single worked thread sounds easier to test and debug. Reminds me of how print queues are managed in unixish systems by moving jobs between directories to express their states - very testable, hackable and transparent. -Bertrand
