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

Joel Garry wrote:

> Anthony Mandic wrote:
>
> > 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.

        Only if that lock was held for longer than it ought to have been.

> 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.

	No, I've been implying that "read for update" or "select with lock"
	or whatever its called is the wrong approach. The read/select
	should not be part of the real transaction. They could be held
	indefinitely, in theory. The real tansaction is the
insert/update/delete.
	These should be fast. If there are a lot of them in one hit, I'd
	consider rethinking the approach used to design the app that
	does this. The implication here is that the app may be far too
	complex, thus being more vulnerable to problems. Keeping it
	simple never hurts.

-am Received on Thu Nov 27 1997 - 00:00:00 CET