Re: Lock detection and resolution

From: Vikas Agnihotri <onlyforposting_at_yahoo.com>
Date: 25 May 2001 06:26:02 -0700
Message-ID: <77e87b58.0105250526.694b7703@posting.google.com>

"Howard J. Rogers" <howardjr_at_www.com> wrote in message news:<3b0db2f1$1_at_news.iprimus.com.au>...
> "Nuno Souto" <nsouto_at_nsw.bigpond.net.au.nospam> wrote in message
> news:3b0d3b9e.23188499_at_news-server...
>
> That's the developers' solution. Personally, I'd hit John around the head a
> bit and tell him not to be so daft as to go for a cup of coffee in the
> middle of a transaction on what is evidently a busy OLTP system. And that's
> straight out of the "physical force" school of DBA techniques. Much more
> satisfying too.

Well, I was oversimplifying. I realize the user-training aspect of application design.

But, in any OLTP system, I would think this sort of thing is not THAT uncommon.

I mean, call it going for a cup of coffee or whatever, but every interactive app's transaction needs some human to digest the information on the screen, possibly make some calls, and then commit/rollback the txn.

During this time, some other user of the OLTP could try to grab that same account/whatever, right?

So, a well designed app should *always* include the 3-step approach that Tom Kyte outlined to prevent this locking situation.

Thanks... Received on Fri May 25 2001 - 08:26:02 CDT