Here are some facts (as I understand them) about EJBs. There are two kinds of EJBs: session beans and entity beans. Sessions beans are essentially helper objects; they exist so that clients can call methods on them. They are not persistent; the server essentially creates them on demand for clients. They run within the client's transaction context, so any database interactions will be transactional. The technology needed for session beans is not very complex. Entity beans represent persistent objects. In primitive EJB environments (e.g. Oracle 8.1.5) they aren't supported at all. In more sophisticated environments, they are supported with bean-managed persistence (BMP). This means that an entity bean must include methods to save and restore its state, and the framework will call those methods as appropriate. In truly advanced environments (e.g. IBM Websphere), entity beans are supported by container-managed persistence (CMP). This means that the framework provides support for saving and restoring bean state, through a combination of source-time tools and run-time objects. Here's how things are supposed to work in an environment with CMP entity beans. You use some sort of locator service to get a reference to a bean. The EJB framework worries about "activating" the bean - making sure that a Java object exists in memory. The framework worries about instantiating the object and restoring its state, if the object didn't exist in memory, or making sure that its state is up-to-date if it did. When you call methods on the bean, those methods are executed in your transaction context. If other threads are calling methods on the bean in other transaction contexts, then the changes you are making will not be visible to those threads. When you commit the transaction, the framework worries about saving the state of all the changes you made to all beans, before telling you that the transaction was committed. In other words, with a good framework supporting CMP, it all works exactly the way one would want. There are some choices that the framework implementor can make. One is, if the implementation is not going to support distributed processing, then all the beans will always be on the same server. This makes it much easier to make sure that an object's in-memory data matches the contents of the persistent store. A distributed implementation has more work to do. Another is how to manage transactions. The pessimistic approach is (in an RDBMS-based implementation) to lock the database rows corresponding to an in-core object when the object is activated, and only allow the object to participate in one transaction at a time. The optimistic approach is to not lock the rows until commit time. Then you lock the rows and make sure that they haven't been changed since the object was activated. Do that for each object in the transaction. If any objects are out-of-date, abort the transaction. Otherwise commit the transaction. Another is when to activate/passivate beans. If an entity bean is not participating in a transaction, the framework can discard it. Its state is stored persistently, so if someone brings it into a transaction later, the framework can reactivate it. If the bean is backed by an RDBMS, then the framework can even passivate the bean when it's participating in a transaction. (Why did they call it "passivation" instead of "deactivation"? I don't know.) There is also a lot of leeway in the tools provided for a framework. Websphere provides a very sophisticated tool that can actually examine your database schema (for DB2 and Oracle at least) and build CMP entity beans from it. rob
