(explanation of the double update problem)
> What should happen is something like ===> user "A" does a "select for
> update", and then when user "B" goes to fetch the data he is informed that
> the data is locked. But to do this you need to keep the session (whether
> apache:session or not) bound to a single, exclusive db connection across
> http requests..... or so I think....
This is transactionaly correct, but a horrible way to write applications.
What do you do if user A goes away for lunch with the data still locked?
The only workable way to do updates is:
1. read data with no lock, put it on the users screen.
2. at some later date user hits ENTER.
3. read data with lock. If it is not the same as it was at (1) tell the
user that you're sorry and someone else has changed the data.
4. if the data was the same rewrite it with the new data.
--
John Hughes <[EMAIL PROTECTED]>,
CalvaEDI SA. Tel: +33-1-4313-3131
66 rue du Moulin de la Pointe, Fax: +33-1-4313-3139
75013 PARIS.
