On Mon, 2002-12-23 at 11:52, Felipe Schnack wrote: > My application have two types of objects that are constantly created > and destroyed. I believe that they could be pooled in some way (maybe > using commons pooling package. These types are: > 1- Objects that handle user interaction. Basically they are the objects > that actually implement tasks that would be otherwise done using > servlets. In pratice, JSPs send data to them (like html form data) and > they process it and return the results to the browser. These ones i'm > not sure (yet) if I should pool. I'm not familiar with Struts, I would > like to know how it does that. Someone can give me some tips? > 2- These I strongly believe I should cache, and I'm already caching > them, but with an solution designed by myself. I have some database > tables that stores user permissions for the application. Basically, > there are two tables that stores an module ID and who can access it (by > user id, user profession, etc). I was thinking about loading all of them > in memory at system startup and update them from time to time (or using > Observable interfaces)?
I don't fully understand how your application is structured, but here are my general thoughts on pooling and caching of objects. Way back in Java 1.0, creating objects was expensive, so people had the idea of having pools of pre-created objects ready to go, which could be reinitialized with new data. Reinitializing an object was a big performance win over constructing a new object. Times have changed since then. For ordinary objects, creating new objects from scratch is very very fast. I read somewhere that an ordinary PII machine can create something like a million small ordinary objects per second, and can GC them at the same rate. There is absolutely no reason to pool these types of objects. There are, however, objects which are still expensive to create and should be pooled. The obvious examples are database connections, threads, and possibly (possibly) direct buffers. But outside of those areas, don't pool objects. One big reason to not pool objects is for correctness and security. If you are using pooled objects, you have to do lots of checking at every step to see if the object is properly initialized, and to make sure it contains no left-over data. What if the object represents a user session, and somehow users were able to get into other users' sessions because an old object got reused without proper reinitialization? That could be a big problem. We moved from C++ to Java to avoid having to worry about storage management bugs like that. It is best to make objects immutable. This means that after the object is constructed, no externally visible changes to the object can ever occur for the lifetime of the object. Immutable objects are much safer and more correct. This may be counter-intuitive, but immutable objects can also lead to better program performance because their internal data structure can be shared. This also helps on debugging. The object is in a valid state AT ALL TIMES in its existence. Making all the instance members of an object private final really helps catch a lot of bugs at compile time. Caching, on the other hand, is a totally different. Caching objects is definitely a good way to go, especially in web applications where objects often have to be used several times in one page output, and they often come from some kind of "expensive" persistent storage like a db. Go ahead and cache. Put your cache in the servelt context, for instance. Again, make the objects in your cache immutable if possible. This has many advantages, including correctness, performance and thread safety. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
