views:

518

answers:

1

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

+3  A: 

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)

Tom
So, I should set a limit on the cache size, I guess, in order no to consume all the server memory...I thought that the session and the application would be serialized to disk, just like php does with the session
opensas
session is serialized to disk, if needed. But not always. About the cache, if the Map doesn't get astronomically huge, there are no bigger issues, but limiting it is a good idea, if combined with a suitable replacement policy to use when conflicts appear.
Tom
what do you mean with conflicts? I've done a similar thing with classic asp's Application object, and defined dependencies for every cached object, so that if needed I can invalidate (erase) every item that is related to some dependency... I've also set a max age cache, something like an hour... just in case...
opensas