using package variables as shared memory

using package variables as shared memory

Post by Thomas Ky » Mon, 21 Sep 1998 04:00:00




(if that email address didn't require changing)


>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.

Quote:>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.

Quote:>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.

Quote:>thanks in advance

>butun

Thomas Kyte

Oracle Government
Herndon VA

--
http://govt.us.oracle.com/    -- downloadable utilities

----------------------------------------------------------------------------
Opinions are mine and do not necessarily reflect those of Oracle Corporation

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.

 
 
 

using package variables as shared memory

Post by butu » Tue, 22 Sep 1998 04:00:00


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.

I have been able to create a package with upto 2500 NUMBER variables
when I try 3000 it says package too large.

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.

thanks in advance

butun

 
 
 

1. share PL/SQL package variable across sessions?

Is it possible to share package level public items across sessions?

What I wish for is :

create package public_data_cache as
       [static-- visible to all] mirrored_data is table of my_type;
end public_data_cache;

I borrowed the term 'static' from Java, which indicates one instance of a
variable per system.

Kenny

2. Installing SQL 2000 on Terminal Server?

3. Using DTS packages, using Global Variables

4. Copying live to test database

5. ADO connection using Shared Memory

6. MS SQL Server Admin course

7. Balance of using OS cache and shared memory

8. DB2 Client Tools Question

9. Ever used utl_tcp package - share knowledge

10. Shared memory used

11. optimization using Shared memory listen port

12. Not using shared memory for programs

13. SHARED VARIABLE not really SHARED???