Containers will manage many beans simultaneously in the same fashion that the Java WebServer manages many servlets. To reduce memory consumption and processing, containers pool resources and manage the lifecycles of all the beans very carefully. When a bean is not being used, a container will place it in a pool to be reused by another client, or possibly evict it from memory and only bring it back when its needed. Because client applications don't have direct access to the beans--the container lies between the client and bean--the client application is completely unaware of the containers resource management activities. A bean that is not in use, for example, might be evicted from memory on the server, while its remote reference on the client remains intact. When the client invokes a method on the remote reference, the container simply re-incarnates the bean to service the request. The client application is unaware of the entire process.
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
For performance some caching might come in handy. You could use HTTP session or entity EJBs as suggested. Another option would be a stateful session bean. I suggest that you have a look at the java petstore example application if you haven't done so already.
Joined: Apr 25, 2003
Thanks for your replies. In blueprints, catalog is in Shopping cart session bean. Catalog is directly read via DAO (no entity bean)for browsing purposes (Fast lane reader). Can Catalog be stored in some read only cache ( given that product information does not change as often) for better performance? [ August 25, 2004: Message edited by: D. Rose ]
Joined: Aug 02, 2004
Sure you could cache the catalog data. But you need to consider the amount of memory which would be needed to cache the whole catalog. Do you have that much to play with? Some approaches might be to cache only certain data - or cache the results of queries for a certain length of time.
How would you index the cached data? You don't want to reinvent the database functionality... You could cache the data for a query and if the same query comes up again you could give the same results (assuming tha data doesn't change that often). Ask yourself whether the same query is likely to happen many times and if not what is the point of caching?
Originally posted by Louise Elliott: You could cache the data for a query and if the same query comes up again you could give the same results (assuming tha data doesn't change that often). Ask yourself whether the same query is likely to happen many times and if not what is the point of caching?
Taking this as a quite good explanation why not to cache data at all for the purposes given in the requirements.
As a side note, this doesn't obsoletes the utilisation of Fast Lane Readers, right?