Re: Microsoft destroys TPC-C records!

"Michael D. Long" wrote:

> For the sake of accuracy, it is quite possible to implement a
> system that will allow for "select sum(balance) from accounts"
> to run at any point - without being blocked.
>

Yes of course you can avoid this behavior if you implement the transaction logic on the client (or 2nd tier).
Following this logic we could use a "thin" and cheep db server as my sql for example. Why should one pay license fees for oracle or sql7 if the their features are unused?

>
> However, an inexperienced developer (and God knows there are
> enough of them out there) can use a server-side cursor with SS7,
> locate the row, and retrieve the value. Irrespective of the isolation
> level or cursor-type, this simple action will result in a lock being
> place - not on the row - but on the index. The blocking behavior
> results, nonetheless.
>

I wouldn't say that it's a question of inexperience. I know how to overcome the drawbacks of sql 6.5 concerning locking, I just use the capabilities of my developer environment (foe example with VFP) but it doesn't mean I'm happy with this concern. If I must port my application on the web for example, i must port more lines of code, and I must eventually implement the features of VFP which I don't have (there are no remote views in java for example) all manually. That would result in a great overall cost, more bugs and so on.... that's of course only my personal opinion.

>
> The problem can be avoided without resorting to reading uncommitted
> data. All that is required is to simply retrieve only the data required to
> perform the current operation into a client-side disconnected recordset.
> Releasing the cursor clears the index lock, thus eliminating contention.
>
> Mike
Received on Sat Apr 08 2000 - 00:00:00 CDT