RE: Has anyone done any scalability work on dbms

From: Jamadagni, Rajendra <Rajendra.Jamadagni_at_espn.com>
Date: Thu, 22 Jan 2004 04:09:45 -0800
Message-ID: <F001.005DDD80.20040122040945@fatcity.com>

Just remember these words about global contexts ... 'doesn't work correctly in RAC' ...

A global context is "global" only within instance ... not across.

Raj

Rajendra dot Jamadagni at nospamespn dot com All Views expressed in this email are strictly personal. QOTD: Any clod can have facts, having an opinion is an art !

-----Original Message-----
Sent: Wednesday, January 21, 2004 6:54 PM To: Multiple recipients of list ORACLE-L

> Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk> wrote:
>
> Sounds like you just need each user to call allocate_unique
> on startup to get a group-specific handle, then do a
> request in exclusive mode before doing the job and
> a release on completion. Users will then naturally queue
> and resume with minimum lost time.

Yes. We have a stored package with a few global constants and some setup functions that gets called on startup of any forms session. That's where we plan to do the startup work. When needed the forms will then do request/release.

>You could probably
> do the thing just as easily by issuing a select for update
> against a group-id row in a table - but dbms_lock makes
> it easier because it can bypass the normal commit activity.

That is the problem with Forms. It's not always easy to streamline where a commit is gonna be done or not. In fact, the user can initiate the commit or rollback at any stage. So, we needed something a little bit more flexible than the select for update. The dbms_lock was the best I could remember at the time. But I like the global context idea. Will look into that.

Cheers
Nuno Souto
nsouto_at_wizofoz2k.com.au

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Nuno Pinto do Souto
  INET: nsouto_at_optusnet.com.au

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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).

**************************************************************************************
This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.
**************************************************************************************4
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jamadagni, Rajendra
  INET: Rajendra.Jamadagni_at_espn.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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).

Received on Thu Jan 22 2004 - 06:09:45 CST

RE: Has anyone done any scalability work on dbms_lock?