Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.tools -> Memory usage during Cursor Processing using Pro-C

Memory usage during Cursor Processing using Pro-C

From: Mitch Logue <mitchel.logue_at_wcom.com>
Date: Wed, 04 Oct 2000 04:03:30 GMT
Message-ID: <m_xC5.116$bp3.1910@pm02news.wcom.com>

Hello,

   I'm trying to avoid a possible future problem in our application, but am not certain if it's even something I have to worry about.

  There is a potential that my process could sleep for a very long time, thus stacking up a huge number of transactions in the database. Then, when I wake back up my cursor goes out to grab the waiting records, but if that number is really large (and it could be) do I have to let it read all of the waiting records?

  I have modifiable MAX_RECORD_COUNT and MAX_COMMIT_COUNT variables defined in the program that are used to ensure I don't spend too much time on this one process, but, if for some unforseen reason I sleep for a long time--as described above, will Oracle force me to read ALL the records out there, or does it do its cursors like this:

   Go out, grab X number of records (probably determined by the amount of available memory), allow you to proces them (via a fetch), then as they are processed it gets more records from the cursor to fill in the sapce left by those records processed, and allow you to cancel this process at any time. By closing the cursor for instance.

  Hopefully someone will tell me that this is indeed how it does it's cursor procesing. If not, how can I limit the number of records it retrieves. Because as you can see, if I tell it I only want to process, say 10,000 records, but there are 10,000,000 waiting for me, well, I'll NEVER get all the way through the queue of waiting records, and I'm thinking I'll be looking for work :)

  Ok, I hope I described my problem clearly enough and I hope that someone out there knows the answer.

  Thanks in advance for your time,

         Mitch Received on Tue Oct 03 2000 - 23:03:30 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US