concurrency issue

Philip Greenspun's Homepage : Philip Greenspun's Homepage Discussion Forums : 6916 : One Thread
Notify me of new responses
In bullet #7 underneath "Here's the plan:" in exercise 6, we are
asked to create a reservation_id, then in the next bullet to
lock/check/unlock the reservation table to prevent users from
'reloading' their way to bankrupcy. Here's my problem:
since reservation_id's are generated incrementally (is this wrong?)
based on max+1 from reservation_id column, there exists a possibility
of a situation when:
user A fills out ccard info, and submits (according to pset,
nothing is written to db just yet)
user B does same shortly after user A, but _before_
add-2-with-fee-2.tcl acts upon the data from A
the result: user B's transaction fails because he has the same id
as user A.
conclusion: this is not secure, but do we need to worry about this
case? one way to solve this is to keep the table locked across two
scripts (sounds apalling, but maybe it's just me). another way is
to create a dummy row in add-2-with-fee.tcl, and 'update' it in
add-2-with-fee-2.tcl with real values (kludgy).

question: should we ignore this issue (my assumption at this point,
seeing as heavy traffic on lcsweb52 is unlikely), or do something
about this (if not in this case, then if a system is a real, live
heavily-trafficed one)?

thank you. sorry for the long-windedness.

-- Alex Sverdlov, October 6, 1999

Answers

Concurrency

You should build your system to avoid concurrency problems. One option to consider would be putting the "check" and "update" inside the same locked transaction. You do not want to hold a transaction across two scripts. Finally, I believe that you have a sequence that may be useful for generating reservation id's. If you don't, consider making one.

-- Jesse Koontz, October 6, 1999

More on concurrency issue

Something is still not clear to me:

jkoontz@mit.edu says:

> you have a sequence that maybe useful for generating reservation id's

the only other way of generating ids that I've seen so far is to use cc_generate_order_id as described in README for cybercash.c The README unfortunately does not describe this function aside from promising that it returns a unique order ID (what does the ID look like? unique with respect to ALL other IDs this function will EVER generate?). Neither does the code for shoppe seem to use this function (as per grep 'cc_generate_order_id' * in shoppe's untared directory). Where should I look to find something in ACS that has dealt with something like this?

Thanks for you help.

-- Alex Sverdlov, October 6, 1999


Answer to "More...."

Actually, your data model should have included one sequence for each table to generate the primary keys. Look at the .sql files in /web/studentXX/www/doc/sql for examples on how to create a sequence. This is separate from the problem of generating keys for cybercash.

-- Jesse Koontz, October 6, 1999

Jesse's point I guess was that you don't do select max+1 to generate IDs but rather use a SQL sequence. Look up "create sequence"...

-- Hristo Bojinov, October 7, 1999