In article <ap401m$1lra$1_at_sp15at20.hursley.ibm.com>,
Paul Vernon <paul.vernon_at_ukk.ibmm.comm> wrote:
>"Jan.Hidders" <hidders_at_hcoss.uia.ac.be> wrote in message
>news:3db54bbc$1_at_news.uia.ac.be...
>>> When you buy shares on a stock market, you are not able to
>> >lock the price before you buy or sell. On an auction site, locks or lack of
>> >them are part of the business rules underlying the dynamics of the auction.
>> >The concept of transactions attempts to 'black box' these issues, I think
>> >they need to be exposed as part of database design.
>>
>> Sure. If you don't need transactions, then don't use them. But in all the
>> cases you mentioned there is the need to declare a set of 2 or more reads
>> and updates as atomic, viz. with the transfer of money.
>
>What need? Unless we are talking to an system external to the database, I see
>no need for transactions and indeed I see them as harmful. If you could give
>me an example where you believe they are *required* within the users concept
>of the database, please do let me know.
If you have a shared budget that you buy the stocks from then the actions of
(1) reading the current budget and (2) writing the new budget, should not
allow reads and writes of other transactions between them. It's the
classical example of a concurrency problem.
Received on Tue Oct 22 2002 - 16:56:02 CDT
