Filed 14-MAY-2001
Product Oracle Server - Enterprise Edition V7 Product Version  8.1.7 
Platform Intel Windows NT Platform Version No Data 
Database Version 8.1.7 Affects Platforms  Generic 
Priority Severe Loss of Service Status Doc Bug (Response/Resolution) 
Base Bug N/A Fixed in Product Version No Data 

Problem statement:

IT GETS UGA WITH EJB + MTS IN LARGE POOL. 
--------------------------------------------------------------------------------


*** KKASAI 05/14/01 02:28 am ***
I confirmed the following information.
[Oracle8 i Java Developer
fs Guide]-[Oracle8i Java Application Performance 
6-9]
-----------------------
Java Pool Memory
-----------------------
Java pool memory used within a Multi-Threaded Server (MTS)
The shared part of each Java class that is used per session. This includes 
readonly memory, such as vectors, and methods. In total, this can average 
about 4-8 KB for each class.
Some of the UGA used for per-session state of each session is allocated 
from the Java pool memory within the SGA. Since Java pool memory size is 
fixed, you must estimate the total requirement for your applications and 
multiply by the number of concurrent sessions they want to create a total 
amount of necessary Java pool memory. Each UGA grows and shrinks as necessary;
however, all UGAs combined must be able to fit within the entire fixed 
Java pool space.
.
Under MTS servers, which is the case for applications using CORBA or EJB, 
this figure could be very large. Java-intensive, multi-user benchmarks could
 require more than 1GB. Current size limitations are unknown; however, 
it is platform dependent.
-----------------------
Correcting Out of Memory Errors
-----------------------
Running out of memory while compiling
If you run out of memory while compiling (within loadjava or deployejb), 
you should see an error:
A SQL exception occurred while compiling: : ORA-04031: unable to allocate 
bytes of shared memory ("shared pool","unknown object","joxlod: init h", 
"JOX: ioc_allocate_pal")
The cure is to shut down your database and to reset JAVA_POOL_SIZE to a 
larger value. The mention of "shared pool" in the error message is a 
misleading reference to running out of memory in the "Shared Global Area". 
It does not mean you should increase your SHARED_POOL_SIZE. Instead, you must
increase your JAVA_POOL_SIZE, restart your server, and try again.
--------------------------------------------------------
...I confirmed about the above situation.
Then, it confirmed that it might be used with not only shared pool and 
java pool but also large pool.
I confirmed ORA-4031 occurs as follows when it is short of large pool.
------
ORA-04031: unable to allocate XX bytes of shared memory ("large pool",
"unknown object","bind var heap","user uac")
------
And, I confirmed the following information in Bug#1455361.
------
As the log says, this is primarily a database configuration issue. Need to 
bump the large_pool_size or turn it 0 so that all UGA memory is allocated 
from java_pool and not large_pool. 
------
I try test about the above information.
- When large_pool_size was set up, it confirmed that the memory of 4-8KB was 
used in large pool as for the result.
- When large_pool_size wasn't set up, it confirmed that the memory of 4-8KB
was used in java pool.
The above phenomenon has been confirmed with R816 and R817 for NT, Linux.
I think that this description in document must be modified.
Thanks.