Java application object… where is it stored?

Question

I'm thinking about using the java application object to implement a simple cache, to save a few configuration variables, and a couple of xml with often used info...

I'd like to know where is the application data phisically stored (a system file, in memory, db), how can it be configured, and if there's any kind of limitation, like space, concurrency, etc...

Besides, any other concern regarding scalabitlity (both, in size and in concurrency) would be appreciated...

And if anybody can point me some place to find more info, I'll be very glad...

thanks a lot

Answer 1

Objects are stored in the heap. Heap spaced can be managed through the VM's configuration file.

A constructor call is more complicated than an ordinary subroutine or function call. It is helpful to understand the exact steps that the computer goes through to execute a constructor call:

1. First, the computer gets a block of unused memory in the heap, large enough to hold an object of the specified type.
2. It initializes the instance variables of the object. If the declaration of an instance variable specifies an initial value, then that value is computed and stored in the instance variable. Otherwise, the default initial value is used.
3. The actual parameters in the constructor, if any, are evaluated, and the values are assigned to the formal parameters of the constructor.
4. The statements in the body of the constructor, if any, are executed.
5. A reference to the object is returned as the value of the constructor call.

The end result of this is that you have a reference to a newly constructed object. You can use this reference to get at the instance variables in that object or to call its instance methods.

http://www.faqs.org/docs/javap/c5/s2.html

Here are some of the VM configuration parameters

http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp

I once wrote a Cache for xml objects (to call them somehow). A Map with a String key (filename) and a reference to the Object (parsed xml file) sufficed. In addition to that, the cache was a singleton (synchronized). Did the same for caching compiled JasperReports (i got a notable speed bump here, because reports where no longer compiled every single time)