Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server

In article <347BCD23.4F5E_at_agd.nsw.gov.au>, Anthony Mandic <no_sp.am_at_agd.nsw.gov.au> wrote:
>Joel Garry wrote:
>
>> Anthony Mandic <no_sp.am_at_agd.nsw.gov.au> wrote:
>> >Perry Dillard wrote:
>> >
>> >> I'll admit that page level locking has its place, but row level is
>> >> absolutely essential.
>> >
>> > Since when? The level of locking should be transparent to
>> > well written applications. It only becomes an issue with
>> > poorly written ones.
>>
>> No matter how well written the application is, if the page is locked by
>> someone accessing a different row that happens to be on the page where the
>> row you want is, you won't get it. Telling people to make their records
>> bigger so there is only one on a page is a pretty hard sell. Convincing
>> programmers to write correctly is like herding cats. Good luck.
>
> Its the responsibility of the programmers regardless. If they
> were inept and incompetent they'd still produce crap. And end
> users would be quick to notice. Waiting for a lock is the same
> regardless of granularity. Thats why locks should be fast and
> only within the scope of the real transaction. Putting it
> around a select that may or may not eventually create a
> transaction is just plain dumb.

You'd better brush up on granularity. That is the whole problem with page locking, you can get locked by something that you should not care about.

The transaction may need to be long. What you are calling a "real" transaction may be an artificial construct solely to deal with the page-locking problem.
>
>-am

-- 
These opinions are my own and not necessarily those of Information Quest
jgarry_at_eiq.com                           http://www.informationquest.com
http://ourworld.compuserve.com/homepages/joel_garry
"See your DBA?"  I AM the _at_#%*& DBA!