RE: Locking Problem

From: DENNIS WILLIAMS <DWILLIAMS_at_LIFETOUCH.COM>
Date: Fri, 13 Sep 2002 08:08:23 -0800
Message-ID: <F001.004CF893.20020913080823@fatcity.com>

Suman - What front-end tool are you using? Often the locking strategy is part of the front-end tool.

It sounds like your locking strategy is too pessimistic. You shouldn't be locking the record "while users are working on it". Eventually you will have users that go to lunch while the record is locked. Your life as a DBA will be miserable. For most applications, when the user selects the record, do a simple query, don't lock the record. When the user returns the record, hold a momentary lock while the record is updated. This has been satisfactory for almost all applications. Otherwise your application won't scale because the locks get out of control. If you are really paranoid, when the record is updated, you can requery the record and verify it against your original copy to ensure someone didn't change the record while you were working on it. If someone else changed it, give the user an error.

Dennis Williams
DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com <mailto:dwilliams_at_lifetouch.com>

-----Original Message-----
Sent: Friday, September 13, 2002 8:04 AM To: Multiple recipients of list ORACLE-L

Hi Everybody,

I am facing problem while invoice Processing.

We have Invoice_Header table and Invoice_Lines Table.

One Record in Invoice_Header table can have multiple related records in Invoice_Lines.

We have not implemented locking mechanism at header level. So whenever two user working on same invoice it creates problem.

Say One Invoice has 10 lines in Invoice_Lines Table and first user pressed the <Process Invoice> button. It does so many validation and insert records in subledger. Mean while another user can add new lines in same Invoice result is discrepancy in printed copy and system records.

Can anybody tell me how to resolve this issue.

	Thanks
	Suman

DISCLAIMER: Information contained and transmitted by this E-MAIL is proprietary to Mascot Systems Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at Mailadmin_at_mascotsystems.com Before opening attachments, please scan for viruses.

--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Suman S K
INET: SumanK_at_mascotsystems.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: DENNIS WILLIAMS
INET: DWILLIAMS_at_LIFETOUCH.COM

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------