Have you read the spec like Kyle suggested? Because if you haven't then it is quite silly for us to be discussing this. Many of your questions will be answered by simply investing the time in reviewing what the EJB Specification has to say.
Having said that, I will still elaborate on the issue since I am a sucker for punishment.
The EJB Specification defines three commit options. They are named (rather stupidly) A, B, and C.
Commit Option A - This option essentially tells the EJB Container that it
OwNz the database. Therefore, the EJB Container can cache bean instances between transaction and not be forced to reload database state on each access. When people talk about the advantages of Entity Bean caching in an Application Server they are usually referring to Commit Option A (though rarely do they realize that). Unfortunately, most enterprise applications (at least the ones I have worked on) must share their database with other applications and cannot use this caching option.
Commit Option B - This option tells the EJB Container that it is using a shared database. It is okay to keep the bean instance around after the client is done with it... but before it is handed out again the state must be synchronized with the database. When using this option you will *always* see ejbLoad() called when you look up an EJB, even if it hasn't changed since the last use. In general, Commit Option B is what most J2EE applications use and is the default level for many Application Servers.
Commit Option C - This option is very similar to B except that nothing is cached, not even bean instances. Therfore, for each request a new bean instance is created and ejbLoad() is called.
It is important to understand that an EJB Container is not required to support all of these Commit Options. They are just required to support at least one. The various levels are specified to give the Container freedom in decided how manage bean instances. If I had to venture a guess as to why Commit Option C is in the specification then I would probably say because it is the easiest possible option to implement. However, all good Application Servers will support both A and B. To be honest I am not sure you would see much of a performance difference between B and C, today's JVMs are very good at creating objects and the biggest hit is going to be the call to ejbLoad() anyways.
[ June 10, 2004: Message edited by: Chris Mathews ]