RE: Has anyone done any scalability work on dbms_lock?
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 [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 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 [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Pinto do Souto INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
RE: RE: Has anyone done any scalability work on dbms_lock?
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 absolutely fantastically. Dick Goulet Senior Oracle DBA Oracle Certified 8i DBA -Original Message- Sent: Wednesday, January 21, 2004 6:14 PM To: Multiple recipients of list ORACLE-L 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 see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Pinto do Souto INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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.net -- Author: Goulet, Dick INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: RE: Has anyone done any scalability work on dbms_lock?
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. It was easy to implement using dbms_lock - the producers ran a pl/sql loop that requested a share lock (mode 4) on a named resource, and committed at the end of each loop; the consumer also ran a loop but requested an exclusive lock (mode 6) on the same named resource and committed at the end of each loop. Both programs had a little sleep time built in to the loops after the commit. When the consumer got its lock, the producers waited. When the consumer committed, the producers got in, and the the consumer queued on them when it next asked for its lock. 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 appearances: Jan 29th 2004 UKOUG Unix SIG - v$ and x$ March 2004 Hotsos Symposium - The Burden of Proof March 2004 Charlotte NC OUG - CBO Tutorial April 2004 Iceland One-day tutorials: http://www.jlcomp.demon.co.uk/tutorial.html Three-day seminar: see http://www.jlcomp.demon.co.uk/seminar.html UK___February The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, January 22, 2004 4:39 PM 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 absolutely fantastically. Dick Goulet Senior Oracle DBA Oracle Certified 8i DBA -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jonathan Lewis INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: Has anyone done any scalability work on dbms_lock?
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 AM, Nuno Souto at [EMAIL PROTECTED] wrote: 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 issues. Any ideas? TIA. Cheers Nuno Souto [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tim Gorman INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: 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? 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 releasing it. Need to use it in a design, but not sure of any potential performance hits or scalability issues. Any ideas? When sessions acquire the same lock (as asked), only one session can do the work in a given moment. So, it doesn't scale. There will be overhead, but that also is relative to the duration of the work done while the lock is held. Maybe AQ can help, by doing the work asynchronously in the background and so lift the serialization from the primary proces(ses)? Regards, Carel-Jan === If you think education is expensive, try ignorance. (Derek Bok) === TIA. Cheers Nuno Souto [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Souto INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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.net -- Author: Carel-Jan Engel INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: Has anyone done any scalability work on dbms_lock?
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 request. Bear in mind that each request or release will hit the enqueue latch a couple of times, so you could get contention for the latch in the two high-speed options. (Forget the low-speed option, allocate_unique does a commit in mid-stream, which you might be able to hide with a recursive transaction - but the overheads are extreme). Bottom line - for high-speed OLTP type of work, I don't think you will get away with more than a dozen request/release cycles per transaction. 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 - OUG Tutorial April 2004 Iceland One-day tutorials: http://www.jlcomp.demon.co.uk/tutorial.html Three-day seminar: see http://www.jlcomp.demon.co.uk/seminar.html UK___February The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 12:49 PM 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 issues. Any ideas? TIA. Cheers Nuno Souto [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jonathan Lewis INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: Has anyone done any scalability work on dbms_lock?
i think expert one on one has some comments on it. Its in a section referring to building your own insert locks. So if a table is locked, the user gets notified. I read the book last year. From: Nuno Souto [EMAIL PROTECTED] Date: 2004/01/21 Wed AM 07:49:25 EST To: Multiple recipients 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 it is? Need to use it in a design, but not sure of any potential performance hits or scalability issues. Any ideas? TIA. Cheers Nuno Souto [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Souto INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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.net -- Author: [EMAIL PROTECTED] INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: Re: Has anyone done any scalability work on dbms_lock?
nuno-- what level are you trying to scale it to? how long will you hold the locks? I used it last year because only one process could run at a time. seemed to have similiar over head to 'select for update'. If you look at the PL/SQL Packages book by Fuerstein et al(not a real popular book, 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? 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 releasing it. Need to use it in a design, but not sure of any potential performance hits or scalability issues. Any ideas? When sessions acquire the same lock (as asked), only one session can do the work in a given moment. So, it doesn't scale. There will be overhead, but that also is relative to the duration of the work done while the lock is held. Maybe AQ can help, by doing the work asynchronously in the background and so lift the serialization from the primary proces(ses)? Regards, Carel-Jan === If you think education is expensive, try ignorance. (Derek Bok) === TIA. Cheers Nuno Souto [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Souto INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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.net -- Author: Carel-Jan Engel INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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.net -- Author: [EMAIL PROTECTED] INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
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 the system. And if the load it imposes is linear. When sessions acquire the same lock (as asked), only one session can do the work in a given moment. So, it doesn't scale. There will be overhead, but that also is relative to the duration of the work done while the lock is held. So, the overhead is MOL linear? Ie, if the amount of work is very small and the number of requests is very high, nothing is gonna suddenly go South? Maybe AQ can help, by doing the work asynchronously in the background and so lift the serialization from the primary proces(ses)? The work is very small indeed. No need to background anything. Cheers Nuno Souto [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Souto INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: Has anyone done any scalability work on dbms_lock?
- 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 could get contention for the latch in the two high-speed options. OK. Will look out for these just in case. Bottom line - for high-speed OLTP type of work, I don't think you will get away with more than a dozen request/release cycles per transaction. Not a worry, it's a workflow app. A few users but not much load, a little volume. I just need to make sure a given sequence of operations is not undertaken by more than one user per group (one lock/group) and a table lock is way too heavy to do this. Forms 9i, so it's not easy to fudge it with a C exit and I don't like servlets. Much better if I can do the lot in PL/SQL. Thanks again. Cheers Nuno Souto [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Souto INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: Has anyone done any scalability work on dbms_lock?
- 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 pass a key to a servlet. I used it last year because only one process could run at a time. That's what I want, one process per lock. seemed to have similiar over head to 'select for update'. That's weird? I thought it didn't involve table access? If you look at the PL/SQL Packages book by Fuerstein et al(not a real popular book, but I like it)... there is a nifty wrapper for DBMS_LOCK. I based my code off of that. Ah yes, I know the book. May not be popular, but I used it a lot a while ago and it's solid. Thanks, will look that up. Cheers Nuno Souto [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Souto INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
RE: Has anyone done any scalability work on dbms_lock?
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 strictly personal. QOTD: Any clod can have facts, having an opinion is an art ! -Original Message- Sent: Wednesday, January 21, 2004 9:10 AM To: Multiple recipients of list ORACLE-L - 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 could get contention for the latch in the two high-speed options. OK. Will look out for these just in case. Bottom line - for high-speed OLTP type of work, I don't think you will get away with more than a dozen request/release cycles per transaction. Not a worry, it's a workflow app. A few users but not much load, a little volume. I just need to make sure a given sequence of operations is not undertaken by more than one user per group (one lock/group) and a table lock is way too heavy to do this. Forms 9i, so it's not easy to fudge it with a C exit and I don't like servlets. Much better if I can do the lot in PL/SQL. Thanks again. Cheers Nuno Souto [EMAIL PROTECTED] ** 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: Has anyone done any scalability work on dbms_lock?
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 - OUG Tutorial April 2004 Iceland One-day tutorials: http://www.jlcomp.demon.co.uk/tutorial.html Three-day seminar: see http://www.jlcomp.demon.co.uk/seminar.html UK___February The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html - Original Message - Not a worry, it's a workflow app. A few users but not much load, a little volume. I just need to make sure a given sequence of operations is not undertaken by more than one user per group (one lock/group) and a table lock is way too heavy to do this. 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. 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. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jonathan Lewis INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: RE: Has anyone done any scalability work on dbms_lock?
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 see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Pinto do Souto INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
Re: Has anyone done any scalability work on dbms_lock?
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 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 [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Pinto do Souto INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
