Re: Package Data vs Global Variables

A copy of this was sent to RC <rclarence_at_tyc.com> (if that email address didn't require changing) On Wed, 05 Jan 2000 21:30:25 GMT, you wrote:

>
>William Teo wrote:
>>
>>
>> Hi,
>>
>> Currently I am working on a security module and the design of the program
>> requires me to store all user rights(previllege) in as flags. When
>security
>> checks in required, I simply reference these pre-initialised flags.
>>
>> One solution is to initialised a list of global variables and set the
>flag
>> when the form is first instantiated. Another solution is to declare this
>> list of flag in a package data section and then initialised it also when
>the
>> form start up.
>>
>> My question is which method is better?
>> By storing the list of variables(possibly ~100s) in a package, it will be
>> available throughout the session. But that will take up memory on the
>> server side !
>> Assuming I have 60 users, wouldn't it have a severe impact on the server
>> performance?
>>

doubtful, unless you are totally starved for memory already. A couple of hundred Y/N or numeric flags isn't going to be an undue burden. We do this all of the time.  

>> Thanks.
>>
>>
>If you initialize the variables in a Package, you have a couple of options.
> You can pin that section of code in memory with DBMS_SHARED_POOL.KEEP.
>This will effective cahce the package in the SGA so it won't be swapped
>out. It will also allow all your users to access to those package
>variables sionce they will share that memory space. This should reduce
>some of the memory usage for your users.
>

keeping it will just make the package stay in the shared pool. Everyone would share the 'text' (instructions) regardless of whether the code was kept or not -- just like an OS typically does.

on the other hand -- we *never* share the 'data' segment of a plsql program. every session will have its own data segment. shared text, private data. Every session would have its own data and stack. every session would have its OWN copy of its variables.

>HTH
>
>RC

--
See http://osi.oracle.com/~tkyte/ for my columns 'Digging-in to Oracle8i'... Current article is "Part I of V, Autonomous Transactions" updated June 21'st  

Thomas Kyte                   tkyte_at_us.oracle.com
Oracle Service Industries     Reston, VA   USA

Opinions are mine and do not necessarily reflect those of Oracle Corporation Received on Wed Jan 05 2000 - 16:03:30 CST