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
Well, I don't know about anyone else, but I make use of it to synchronize data upload
programs for our testers. Can't have two instances of the upload program processing
the same tester, they'd duplicate data. Anyhow, we normally run 4 instances of this
program the dbms_lock package works
I came across a very nice example a while ago
where there were 4 concurrent sessions feeding
data into a holding table, and one session consuming
from the table.
The rules said that the consumer could not run
while the producers were loading the table, but
multiple producers were allowed to run.
DBMS_LOCK manipulates the same enqueue mechanism that Oracle uses for just
about everything. Same as every other type of lock shown in V$LOCK, just
type = UL.
Thus, any problems in DBMS_LOCK would be shared by just about every facet of
session-level concurrency in the RDBMS...
on 1/21/04 5:49
As in: does it present an inherent or hidden performance
problem when a lot of sessions try to lock/release the same
lock? Or how many lock/release per second. Or some other
idea of how efficient it is?
Need to use it in a design, but not sure of any potential
performance hits or scalability
As in: does it present an inherent or hidden performance
problem when a lot of sessions try to lock/release the same
lock?
Will serialize perfectly!
Or how many lock/release per second. Or some other
idea of how efficient it is?
Depends on the work done between acquiring the lock and
On a light-weight test on 8.1.7.4 at 700MHz on W2000 -
About 15,000 request/release per second
if you are using an ID
About 8,000 request/release per second
if you are using a pre-allocated lock handle
About 800 request/release per second
if you have to allocate_unique on every
of list ORACLE-L [EMAIL PROTECTED]
Subject: Has anyone done any scalability work on dbms_lock?
As in: does it present an inherent or hidden performance
problem when a lot of sessions try to lock/release the same
lock? Or how many lock/release per second. Or some other
idea of how efficient
, but I like it)... there is a
nifty wrapper for DBMS_LOCK. I based my code off of that.
From: Carel-Jan Engel [EMAIL PROTECTED]
Date: 2004/01/21 Wed AM 08:24:25 EST
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: Re: Has anyone done any scalability work on dbms_lock
- Original Message -
Or how many lock/release per second. Or some other
idea of how efficient it is?
Depends on the work done between acquiring the lock and releasing it.
Not really. I'm asking how many lock/releases can be done
before the thing starts putting a serious load on
- Original Message -
On a light-weight test on 8.1.7.4 at 700MHz on W2000 -
About 15,000 request/release per second
if you are using an ID
sounds plenty good to me. Thanks a lot.
Bear in mind that each request or release will hit the
enqueue latch a couple of times, so you
- Original Message -
nuno-- what level are you trying to scale it to?
Not much. A few hundred users, maybe 20 or so may
need the lock. However, this app may explode in
# users, so I want to make sure I'm not creating
a monster.
how long will you hold the locks?
only long enough to
if it is single instance you could also use global application contexts ... (alas they
don't work in RAC across node) ...
Raj
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are
Note in-line
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The educated person is not the person
who can answer the questions, but the
person who can question the answers -- T. Schick Jr
Next public appearance2:
March 2004 Hotsos Symposium - Keynote
March 2004 Charlotte NC -
Hmm, that's actually a very good idea.
It might actually do the job here. Thanks.
Nuno Souto
[EMAIL PROTECTED]
Jamadagni, Rajendra [EMAIL PROTECTED] wrote:
if it is single instance you could also use global application
contexts ... (alas they don't work in RAC across node) ...
--
Please
Jonathan Lewis [EMAIL PROTECTED] 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
16 matches
Mail list logo
