Basic objects/services hosted in a java server

For a basic web server, the resources (on disk) and objects (in memory) hosted in the server are mostly static files.

For a php/perl/python powered web server, the objects hosted would be the scripts to print html. There are almost always some resources beneath those scripts.

Simpler example — for an ftp server, the resources managed are the files.

Another simple example — time server. The resource beneath the server is the host OS.

For a database server, the resources managed by the server are the tables. The server performs heavy-duty CRUD operations on the tables. The most trivial operation — a simple select — is comparable to apache serving a static page.

For a CORBA or RMI server, there are actual “remote” objects and corresponding “skeleton” objects hosted in the server’s memory.

How about a regular java server? Resources — disk files, and databse and other servers on the network. More important are the objects hosted in the java server. They all live in JVM.
* domain entity objects are well-defined, such as
** (Hibernate) entity objects from data sources,
** message objects, and
** objects created from user input
** more generally, objects from external data brought into java via some interface are usually domain entity objects.
* temporary objects — can lead to memory leak if not reclaimed systematically. * infrastructure objects, such as spring beans and MOM system objects. I think 3rd party java packages often introduce many infrastructure objects.

weblogic multipool

useful when you have 2 database instances (perhaps on 2 DB boxes) that are not a DB cluster. What’s their relationship? Perhaps a replica.
 
If the 2 db instances form a db cluster, then a db client ( your servlet ) gets a single point of contact — no need for fancy multipool. The DB cluster /masquerades/ as a single regular DB instance.

weblogic jdbc "query cache"

the first time a query is run, Liquid Data saves its results into a query results cache. The next time the query is run with the same parameters, Liquid Data checks the cache configuration and, if the results have not expired, quickly retrieves the results from the cache.

similar to EHcache read-only mode

container managed relationships, in a Lead-management system

Let’s read about cmr and cross check Binu’s observations

Lead management system, with 60 tables, each represented by a cmp bean.

in only 2 cases, the inter-bean relationship was managed by container-managed relationship. One of the 2 was the Lead-Address relationship, where each lead id is linked to an Address bean. When container loads a particular Lead beam from the DB, the associated Address bean was loaded too. When saving the beans to DB, we used the SLSB to save the Lead bean and the Address bean separately

A: performance. Hibernate has replaced cmr in subsequent projects.
A: The slsb facade is the only “client”. Using local interface.
A: Use ejb-ql.

A: basically nothing but ORM. The entity beans are related as in the DB, so the objects need2b linked up in some way.

Q: Why the majority of the relationships are not by cmr?
Q: how are the cmp beans used in terms of clients?

Q: How does the system know which Address bean to load for a given Lead bean?

Q: j4cmr]this project?

context-scope = application-scope

I have seen authors using the twin terms “context-scope” and “application-scope” interchangeably.

This is the first thing to bear in mind. After that, recognize that

* context-scope is related to ServletContext, a name used repeatedly in some files
* application-scope is related to web-app, a name used in some files too.

Lastly, remember that we are talking about ATTRIBUTES when we mention these scopes ie

context-scope attributes = application-scope attributes

P309 [[ head first servlet ]]