Nicolas Williams wrote:
On Wed, Dec 06, 2006 at 11:36:11AM -0600, John Stanton wrote:
I fully understood. It is an age old problem that has puzzled
generations of system designers. My first exposure was over thirty
years ago. The approach we discovered worked was to treat it as a
transaction in the logical sense. The decision then becomes one of
granularity because obviously you cannot keep the whole DB locked to
handle one item if you have multiple users.
Logic using a committed journal and an application implemented rollback
and commit can effectively implement the transaction in a multiple user
environment.
Another alternative is to run
UPDATE ... SET ... WHERE column1 = <value_read_earlier> AND column2 = ...
and then check if the update happened -- if it didn't it's because the
data read earlier was stale; recover by re-selecting the data, etc...
Let the user see what SQL is executed, let them type in their own, and
by and large you're there.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
To fully handle the situation you need to know how many users have a
transaction pending and are pondering ordering the item. That requires
some form of journal or "committed" total. If you have three items and
there are three people part way through an order then you really don't
have any stock until one of the three releases.
It is not nice to mislead a customer that an item is available only to
fail to ultimately fulfil the order.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
