| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: using package variables as shared memory
A copy of this was sent to butun <butun_at_ezy.net.au>
(if that email address didn't require changing)
On Mon, 21 Sep 1998 00:41:31 +1000, you wrote:
>Hi
>
>I am trying to use the global varibles declared in a bodiless package
>as a means of storing/accessing data at high speeds. I have got 40000
>read write
>pairs on a 586 PC.
>
won't work... package specs contain SESSION specific data. PL/SQL is executed in a manner similar to a program running in Unix. The code is shared across many instances of the process but the data is specific to a process.
Likewise, a pl/sql package state is unique to each and every logon. You have to use some sort of IPC mechanism such as dbms_pipes or dbms_alert to convey data from session to session without using a table.
>I have been able to create a package with upto 2500 NUMBER variables
>when I try 3000 it says package too large.
>
well, you could use a pl/sql TABLE of numbers.
create package my_pkg
as
type myArray is table of number index by binary_integer;
theData myArray;
end;
/
One variable could then hold many values in an array.
>Is this a hard coded Oracle8 limit? or is there a resource I can
>increase.
>
>I would like to be able to read/write the bodiless package data from
>multiple different
>application processes written in C++ or java. The data in the bodiless
>package can only be
>accessed from a single session. Does anybody have an idea how to get
>around this
>limitation without adding too much overhead.
>
I myself think you are trying to solve a 'supposed' problem that will not exist in reality (the problem you are assuming to exist won't exist -- that of the performance of database tables).
If you have many processes constantly reading this data you should just put it in a table and let them use SQL, SELECTs to read, UPDATES/INSERTS to write. Since the amount of the data will be relatively small and frequently accessed -- the database buffers which are in real shared memory will always contain the data. In fact, you could hint to the database that this iis the case by issuing "alter table TNAME cache".
I'd give the table a chance -- at least benchmark it, you'll be surprised. Since you have many readers/writers you won't even have to write the needed mutexes and serialization code to ensure consistent data as you would if you did it with variables -- the database does this already for you.
>thanks in advance
>
>butun
>
>
>
Thomas Kyte
tkyte_at_us.oracle.com
Oracle Government
Herndon VA
--
http://govt.us.oracle.com/ -- downloadable utilities
Anti-Anti Spam Msg: if you want an answer emailed to you, you have to make it easy to get email to you. Any bounced email will be treated the same way i treat SPAM-- I delete it. Received on Sun Sep 20 1998 - 10:15:49 CDT
 |
 |