Oracle normally maintains the state of package-level constants, cursors, and variables in your UGA for as long as your session is running. Contrast this behavior with the variables instantiated in the declaration section of a standalone module. The scope of those variables is restricted to the module. When the module terminates, the memory and values associated with those variables are released. They are no more.
In addition to disconnecting, several other things can cause a package to obliterate its state:
· Someone recompiles the program, or Oracle invalidates it, as discussed earlier.
· The DBMS_SESSION.RESET_PACKAGE built-in procedure executes in your session.
· You include the SERIALLY_REUSABLE pragma (see Chapter 17) in your program, which causes Oracle to retain state only for the duration of the call, rather than for the entire session.
· You are using the web gateway in the default mode which by default does not maintain persistent database sessions for each client.
Subject to these limitations, package data structures can act as "globals" within the PL/SQL environment. That is, they provide a way for different PL/SQL programs running in the same session to exchange data.
From an application design perspective, there are two types of global data: public and private.
Public
A data structure declared in the specification of a package is a global public data structure. Any calling program or user with EXECUTE privilege has access to the data. Programs can assign even meaningless values to package variables not marked CONSTANT. Public global data is the proverbial "loose cannon" of programming: convenient to declare but tempting to overuse, leading to a greater risk of unstructured code that is susceptible to ugly side effects.
The specification of a module should give you all the information you need to call and use that module. If the program reads and/or writes global data structures, you cannot tell this from the module specification; you cannot be sure of what is happening in your application and which program changes what data. It is always preferable to pass data as parameters in and out of modules. That way, the reliance on those data structures is documented in the specification and can be accounted for by the developer. In my own code, I try to limit global public data to those values that can truly be made CONSTANT.
Private
Not so problematic are global but private data structures (also called package-level data) that you might declare in the body of the package. Because it does not appear in the specification, this data cannot be referenced from outside the package—only from within the package, by other package elements.
