These are some of the points that I made while studying and doing some mock exams. Hope it will be of some help to you people. Sorry, it's not so well organized and aligned. Do let me know if I have made any mistakes in my points. Please keep adding to this thread your points and thus we can help others who are preparing for the exam.
ALL THE BEST !!!
1. The following are considered to be goals of the EJB 2.0 Specification:
* Define the integration of EJB with the Java Message Service.
* Provide a local client view and support for efficient, lightweight access to
enterprise beans from local clients.
* Provide improved support for the persistence of entity beans.
* Provide improved support for the management of relationships among entity beans.
* Provide a query syntax for entity bean finder methods.
* Provide support for additional methods in the home interface.
* Provide for network interoperability among EJB servers.
The following are goals of the EJB architecture:
* The Enterprise JavaBeans architecture will be the standard component architecture for
building distributed object-oriented business applications in the Java programming language.
* Application developers will not have to understand low-level transaction and state
management details, multi-threading, connection pooling, and other complex low-level APIs.
* An enterprise Bean can be developed once, and then deployed on multiple platforms without
recompilation or source code modification.
* The Enterprise JavaBeans architecture will define the contracts that enable tools from
multiple vendors to develop and deploy components that can interoperate at runtime.
* The Enterprise JavaBeans architecture will be compatible with existing server platforms.
Vendors will be able to extend their existing products to support Enterprise JavaBeans.
* The Enterprise JavaBeans architecture will be compatible with other Java programming
* The Enterprise JavaBeans architecture will provide interoperability between enterprise
Beans and Java 2 Platform Enterprise Edition (J2EE) components as well as non-Java programming
* The Enterprise JavaBeans architecture will be compatible with the CORBA protocols.
2.Enterprise Bean provider: The Enterprise Bean Provider is the producer of enterprise beans. His or
her output is an ejb-jar file that contains one or more enterprise beans.
Application Assembler: The Application Assembler combines enterprise beans into larger deployable
application units. The input to the Application Assembler is one or more ejb-jar files produced by the
Deployer: The Deployer takes one or more ejb-jar files produced by a Bean Provider or Application Assembler
and deploys the enterprise beans contained in the ejb-jar files in a specific operational environment.
EJB Server Provider: The EJB Server Provider is a specialist in the area of distributed transaction management,
distribute objects, and other lower-level system-level services. A typical EJB Server Provider is an
OS vendor, middleware vendor, or database vendor.
EJB Container Provider: The EJB Container Provider (Container Provider for short) provides:
1) The deployment tools necessary for the deployment of enterprise beans and
2) The runtime support for the deployed enterprise bean instances.
System Administrator: The System Administrator is responsible for the configuration and administration
of the enterprise's computing and networking infrastructure that includes the EJB Server and Container.
3.Parameters are passed by value when used remotely
Parameters are passed by reference when used locally.
4. When fetching frequently used read-only data, a stateless session bean should be used.
5.The SERIALIZED DD and ejb-jar MANIFEST file have been deprecated in EJB 2.0
6.Multiple clients can access the same EJBObject concurrently ( I think for stateless and entity beans).
7.Static variables should be final
eg :- private static final x;
8.NON-SERIALIZABLE Objects cannot be accessed remotely.
9.Only the send part of Javamail is available to an EJB.
1.Any methods associated with a primary key defined by a local home or component interface
raises a javax.ejb.EJBException if the method is invoked on a session bean. Likewise, any methods
associated with a primary key defined by a remote home or component interface raises a
java.rmi.RemoteException if the method is invoked on a session bean.
1. A session object�s conversational state is not transactional. It is not automatically rolled back
to its initial state if the transaction in which the object has participated rolls back.
If a rollback could result in an inconsistency between a session object�s conversational state and the
state of the underlying database, the bean developer (or the application development tools used by the
developer) must use the afterCompletion notification to manually reset its state.
2. Since a session bean instance�s conversational state is not transactional, it may need to
manually reset its state if a rollback occurred.(using SessionSyncronization)
3. The container may not call the beforeCompletion method if the transaction has been
marked for rollback (nor does the instance write any cached updates to the database).
4. A session bean can be passivated only between transactions, and not within a transaction.
5. The ejbRemove() method cannot be called when the instance is participating in a transaction.
6. A session bean instance can participate in at most a single transaction at a time.
(Also don't try to interrupt this transaction from the client side, by calling this
same method in a diff tx or in an unspecified tx).
7. The home interface of a stateless session bean must have one create method that takes no arguments.
8.Transaction in stateless Session beans :-
Because all instances of a stateless session bean are equivalent, the container can choose to delegate a
client-invoked method to any available instance. This means, for example, that the Container may delegate
the requests from the same client within the same transaction to different instances, and that the
Container may interleave requests from multiple transactions to the same instance.
9. A stateless session bean must not implement the javax.ejb.SessionSynchronization interface.
10. All beas(session/entity) should have a public constructor that takes no parameters. The Container
uses this constructor to create instances of the session bean class.
11.An EJB 2.0 compliant enterprise bean should not throw the java.rmi.RemoteException from the ejbCreate method .
12.RemoteException from Business methods:-
EJB 1.0 allowed the business methods to throw the java.rmi.RemoteException to
indicate a non-application exception. This practice was deprecated in EJB 1.1�an EJB 1.1 or
EJB 2.0 compliant enterprise bean should throw the javax.ejb.EJBException or another RuntimeException
to indicate non-application exceptions to the Container (see Section 18.2.2).
An EJB 2.0 compliant enterprise bean should not throw the java.rmi.RemoteException from a business method.
(MAKE THIS CLEAR !!!)
13.The remote interface methods must not expose local interface types, local home interface
types, or the managed collection classes that are used for entity beans with container-managed
persistence as arguments or results.
Because a Local Home/object won't know how to marshall a method call since it's outside the JVM and
also it uses RMI instead of RMI-IIOP.
14.The methods for a stateless session bean must be named �create� and �ejbCreate�. And not
15. The throws clause of a method defined in the local interface/local home interface must not
include the java.rmi.RemoteException.
16.The container generated classes "implements" the interfaces the bean developer writes.
The deployment tools are responsible for implementing the handle classes for the session bean�s remote
home and remote interfaces.
The deployment tools are responsible for implementing the class that provides meta-data to the remote
client view contract.
17.Note that a session object is intended to support only a single client. Therefore, it would be an
application error if two clients attempted to invoke the same session object.
BUT --> In a case with the stateless session beans one bean instance can service multiple clients as
long as the clients are not concurrent.
220.127.116.11 (MAKE THIS CLEAR !!!)
19.All methods in the remote home and remote component interfaces are defined to throw
"java.rmi.RemoteException". (And NOT javax.rmi............).
20.A session bean's conversational state is not transactional and is not automatically reset to its initial
state if a transaction is rolled back. The afterCompletion notification may be used to manually reset
the bean instance's conversational state in the event of a transaction roll back.
21.New stateless session bean instances are created when is it necessary to handle an increase in client
work load. Also the container decides when to remove the session object, no matter whether the client called
remove or not.
22.The "java:comp/env" environment space is only used for EJB references *inside* the server. External lookups
in remote client should use the "real" JNDI name of your EJB. Dig around to figure out what this is.
Possibilities include "ejb/Ordine" or "Ordine".
23.Session beans executes on behalf of only one client at a time.
24.If a session bean implements SessionSynchronization interface, then the app assembler may ONLY SPECIFY
Required, RequiresNew or Mandatory attributes
25.Create methods can be OVERLOADED , EXCEPT for stateless Session beans.
1.the persistent state of the instance at the beginning of the ejbRemove() method
is the same as it would be at the beginning of a business method. The container must
invoke ejbLoad before it invokes ejbRemove().
2.Entity beans should be in the same local scope if they have a relationship.
3. The bean proider can manipulate the relationships at runtime via get and set accessor method.
4.For ejbSelect method, the container should make sure that no duplicates are returned.
5.Invoking javax.ejb.EJBContext.getUserTransaction() in an entity bean instance method results in
java.lang.IllegalStateException because entity beans must always use container-managed transactions.
6.In ejbActivate, initialize transient fields. Since the transient fields are not preserved while serialization-
deserialization process, you need initialize such fields to appropriate values in ejbActivate() method
7.Customer 0..1 ----------- 0..* Address
What will be the result of the follow method call made by a client?
This call is illegal. It should pass an empty Collection object if it wants to remove all the addresses for a
8.With container-managed persistence, the container performs the database insert after the ejbCreate(...) method
completes (anytime after this).
9.The Container must establish the primary key before it invokes the ejbPostCreate(...) method.
10.The container synchronizes the instance�s state before it invokes the ejbRemove method. This means
that the state of the instance variables at the beginning of the ejbRemove method is the same as it
would be at the beginning of a business method.
ejbActivate()/ejbLoad is called prior to calling ejbRemove().
To synchronize instance's state, call ejbLoad().
To synchronize entity object's state in db, call ejbStore().
11.Valid types of persistent CMP fields of a 2.0 CMP entity bean
A primitive type.
All serializable types
12.Caller of the finder method must always be prepared for FinderException.
13.The lack of a local interface prevents other entity beans from having a relationship
14.The abstract-schema defines the bean's persistent fields and relationships.
It is used ONLY with CMP.
15. All static fields in the bean should be marked FINAL.
16.CMR can only exists among entity beans with the same LOCAL RELATIONSHIP SCOPE
17.For ejbSelect method, the container should ensure that NO DUPLICATES are returned.
The collection of values returned by the Container may contain duplicates if DISTINCT is not specified
in the SELECT clause of the query for the finder method.
A client program must use the PortableRemoteObject.narrow(...) method to convert the
objects contained in the collections returned by a finder method on the entity bean�s remote home interface
to the entity bean�s remote interface type.
finder methods :- EJBObjects or EJBLocalObjects of the same type as the entity bean (or collection of it)
select methods :- EJBObjects, EJBLocalObjects, or cmp-field types (or collection of it),
or cmr-field types (or collection of it).
21.If a single object return finder/select method returns more than one values, then it should throw a
The cascade-delete element can only be specified for an ejb-relationship-role element contained in an
ejb-relation element if the other ejb-relationship-role element in the same ejb-relation element
specifies a multiplicity of One. The cascade-delete option cannot be specified for a many-to-many relationship.
23.The ejbSelect method MUST define javax.ejb.FinderException.
24.Home methods cannot be declared static.. ( ie it can be declared final)
Select methods can be declared static and final. (well, this is abstract by default)
create method/business method cannot be declared final OR static
25.The Container MUST establish the primary key BEFORE it invokes the ejbPostCreate<METHOD>(...) method.
26.The instance is in the READY STATE when ejbRemove() is invoked and it will be entered into the POOL
when the method completes.
The container synchronizes the instance�s state before it invokes the ejbRemove method
27.For CMP, no need to define a default constructor. A default one will be provided.
28.ejbLoad(), ejbStore() and business methods can be called in ANY order.
29.Container needs to call ejbActivate(), ejbLoad() before it can call a ejbRemove().
30.ejbLoad(), ejbRemove(), ejbSelect() --> runs in the tx context of the method that causes it's invocation.
Other beans in the same app using the same resource, in the same tx can share.
32.If entity beans uses UserTx methods, a javax.naming.NameNotFoundException will be thrown ???
33.Create methods can be OVERLOADED
34.BEWARE OF the word "EXISTING OBJECT" and "NEW OBJECT".
1.domain of a query may be restricted by the navigability of the relationships of the entity
bean on which it is based. The cmr-fields of an entity bean's abstract schema type determine navigability.
Using the cmr-fields and their values, a query can select related entity bean's and use their abstract
schema types in the query. The '.' operator is the navigation operator used to navigate through
container managed relationships.
2.The data model for container-managed persistence does not support inheritance. For this reason
entity objects or value classes of different types cannot be compared. Any EJB QL queries that
contain such comparisons are invalid.
3.Another restriction regarding the use of EJB QL is that date and time values should use the standard
Java long millisecond value.
4.The following are the reserved identifiers in EJB QL: SELECT, FROM, WHERE, DISTINCT, OBJECT, NULL, TRUE, FALSE,
NOT, AND, OR, BETWEEN, LIKE, IN, AS, UNKNOWN (not used as yet but reserved), EMPTY, MEMBER, OF and IS.
5.IS NULL is used to test whether a cmp-field or single-valued cmr-field value is NULL.
IS EMPTY tests whether or not the collection designated by the collection-valued path expression
is empty (i.e., has no elements).
(A collection-valued path expression can only be used in the WHERE clause in an empty collection comparison
expression or in a collection member expression.)
6.must define names used by entity beans in query : - Abstract Persistance Schema
can be declared in a FROM clause optionally using AS or IN :- Identification Variables
constrain the query domain :- Path Expressions
way to reference arguments from finder and select methods :- Input Parameters
7.ORDER BY is NOT supported in EJB-QL
8.Functional expressions: CONCAT, SUBSTRING, LOCATE, LENGTH, ABS, SQRT
9.Conditional expressions can use:
operators (+ - * /)
comparisons (= > >= < <= <> , for strings only = and <>
BETWEEN arithmetic-expression AND arithmetic-expression
IN: value IN (value1, value2, ...)
LIKE, using wild card characters _ and %
null comparison: IS NULL
empty comparison: collection-valued-path-expr IS EMPTY
collection member expression: MEMBER OF collection-valued-path-expr
functional expressions: CONCAT, SUBSTRING, LOCATE, LENGTH, ABS, SQRT
10.A null comparison expression tests whether or not the single valued path expression is a NULL value. Path
expressions containing NULL values during evaluation return NULL values.
Select all Customers whose name begins with S and are older than customer Joe Bloggs
Select Object(c1) from Customer c1,Customer c2 where c1.age > c2.age and c2.name='Joe Bloggs'
1. Calling remove twice on a bean results in java.rmi.NoSuchObjectException.
similarly, calling a business method on an already removed bean.
2.Invoking javax.ejb.EJBContext.getUserTransaction() in an entity bean instance method results in
java.lang.IllegalStateException because entity beans must always use container-managed transactions.
3.When the bean provider tries to reset the primary key value by means of a set method on any of the CMP
fields after it has been set in the ejbCreate method, it throws IllegalStateException.
4.EntityContext.getEJBObject() results in a java.lang.IllegalStateException when the entity bean does not define a
remote client view.
5.The container does not always throws a RemoteException when the tx is rolledback, but it MAY rollback
the tx when the remoteException occurs.
6.The Container MUST detect an attempt to assign a removed entity object as the value of a cmr-field of another
object (whether as an argument to a set accessor method or as an argument to a method of the
java.util.Collection API) and throw the java.lang.IllegalArgumentException.
7.If the argument to the set accessor method is NOT of the same type as the cmr-field, the container MUST
throw the java.lang.IllegalArgumentException.
8.Invoking javax.ejb.EJBObject.getPrimaryKey() on session beans throws RemoteException
Invoking javax.ejb.EJBLocalObject.getPrimaryKey() on session beans throws EJBException
Invoking javax.ejb.EJBHome.remove(java.lang.Object primaryKey) on session beans javax.ejb.RemoveException
9.If the container fails to start or commit a CMT, the container must throw RemoteException/EJBException
(For MDB- EJBException)
10.RemoteException/EJBException - indicates a failure to invoke an enterprise bean method or to properly
complete it's invocation.
11.If a client receive's RemoteException/EJBException, he can
(a) Discontinue Tx :- By calling rollback() or throwing a RuntimeException (if it's not the tx orginator)
(b) Continue Tx :- By first enquiring the tx status and then committing it.
12.In case of a CMT:-
If the bean method throws an application exception but does not mark the transaction for rollback,
the container will commit the transaction before re-throwing the application exception to the client.
If the bean method marks the transaction for rollback, the container will roll back the transaction
before re-throwing the application exception to the client.
13.If the Container denies a client access to a business method, the Container must throw
the java.rmi.RemoteException to the client if the client is a remote client, or
the javax.ejb.EJBException if the client is a local client.
1.The system administrator is responsible for adding, removing and configuring resource managers
in the EJB environment.
2.Can Environment entries can be shared with different enterprise beans ???
Since the value of the res-auth element is Container, the deployer is responsible for configuring the
sign-in information of the resource manager by supplying the principle mapping information.
On the other hand, if the value of the res-auth element was Application the bean provider would be
responsible for performing a sign-on to the resource manager programmatically in the enterprise bean code.
4.Managed Resources :- The connections acquired through the resource manager connection factory references
are called managed resources.
Managed by J2EE container itself.
Administered Objects :-Managed by a separate server like a JMS provider or a JavaMail server.
5.Enterprise bean instances are NOT ALLOWED to modify the bean's environment at runtime.
6.Environment entry is INACCESSIBLE from other enterprise beans at runtime, and that other enterprise beans
may define env-entry elements with the same env-entry-name without causing a name conflict.
7.<env-entry> are NOT UNIQUE for instances of the same bean type. They share.
1.The following are the requirements for the message-driven bean class:
The class must implement, directly or indirectly, the javax.ejb.MessageDrivenBean interface.
The class must implement, directly or indirectly, the javax.jms.MessageListener interface.
The class must be defined as public, must not be final, and must not be abstract.
The class must have a public constructor that takes no arguments.
The Container uses this constructor to create instances of the message-driven bean class.
Each message-driven bean class must have one ejbCreate method, with no arguments.
The class must not define the finalize() method.
2.The order is not guaranteed for javax.jms.Topic (but it is for javax.jms.Queue)
3.Container may create multiple instances of the bean but one message will be given to only one bean instance
whether it is bound to a queue or topic.
4.Only one thread will execute a MDB instance at a time.
5.A message-driven bean does not have to be coded as reentrant.
A container allows many instances of a message-driven bean class to be executing concurrently.
6.By default, there is NO tx attribute for onMessage()
7.If a durable topic subscription is used (also Queues), then even if the EJB Server is NOT running, the messages
will NOT be missed.
Non-durable Topics can be missed
8.A container may create multiple instances of the bean but one message will be given to only one bean instance
whether it is bound to a queue or topic.
1.If a security role is defined but not used in any method-permission elements it does not mean
that the role has permission to invoke all methods. A caller with this role will have the same
rights as a caller without a specified security role.
2.The responsibilities as described in the EJB specification state that the Bean Provider and
Application Assembler should describe all the requirements for the caller's principal management of
inter-enterprise bean invocations as part of the description.
3. The Deployer's Role :-
- Along with the Application Assembler define the appropriate security policies for the application.
- Setting up the appropriate security policy for the enterprise bean application.
- Along with the System Administrator setting up of the principal delegation in a Container-specific way.
4.isCallerInRole :- It tests whether the caller of the bean belongs to the role that is passed as a parameter to this
Returns the principal that represents the CALLER of the enterprise bean, not the principal
that corresponds to the run-as security identity for the bean, if any.
boolean isCallerInRole(String roleName);
Tests the principal that represents the CALLER of the enterprise bean, not the principal
that corresponds to the run-as security identity for the bean, if any.
5.Security Policies can be hard-coded but the bean provider is encouraged to write the business methods
WITHOUT any security logic.
1.When an instance attempts to start a transaction using the begin() method of the javax.transaction.
UserTransaction interface while the instance has not committed the previous transaction,
the Container must throw the javax.transaction.NotSupportedException in the
2.The Container must throw the java.lang.IllegalStateException if an instance of a bean
with bean-managed transaction demarcation attempts to invoke the setRollbackOnly() or
getRollbackOnly() method of the javax.ejb.EJBContext interface.
3. If an instance of an enterprise bean with container-managed transaction demarcation attempts
to invoke the getUserTransaction() method of the EJBContext interface, the Container must throw the
4.When the container starts a transaction, it is responsible for controlling the transaction when it
receives an exception. If the bean method throws an application exception but does not mark the
transaction for rollback, the container will commit the transaction before re-throwing the
application exception to the client. If the bean method marks the transaction for rollback,
the container will roll back the transaction before re-throwing the application exception to the client.
5.The container always discards an enterprise bean instance because the bean may end up in an inconsistent
state as a result of the non-application exception thus becoming unsafe for further use.
Discarding the bean prevents both the container and the client from further invoking methods on the bean.
javax.ejb.TransactionRolledbackLocalException (subclass of javax.ejb.EJBException) indicates to the local
client that the transaction has definitely been marked for rollback. Attempting to continue with the
transaction is pointless because the transaction cannot be committed.
Unlike business methods of a session or entity bean, message-driven bean methods do not throw
The container is responsible for performing any clean up actions before throwing a non-application
The container is not responsible for committing or rolling back transactions that have been initiated
by the client.
6.The container is only responsible for rolling back a system exception for an message-driven bean with
container-managed transaction demarcation and when the bean method runs in the context of a transaction
started by the container.
A transaction is not rolled backed by the container as a result of a system exception thrown when the
transaction runs with an unspecified transaction context and also when a bean is declared with
bean-managed transaction demaraction.
7.If a remote client in a transaction context invokes a business method on a bean with container-managed
transaction and the bean throws a non-application exception, the transaction is marked for rollback.
The client then receives javax.transaction.TransactionRolledbackException (subclass of java.rmi.RemoteException)
which indicates that the transaction has definitely been marked for rollback.
8.An application assembler cannot affect transactional behaviour for enterprise beans that use bean-managed
transaction demarcation. The application assembler can only affect transactional behaviour of beans that
use container-managed transaction demarcation.
9.An entity beans can only use the CMT (IS THIS NOT CMP ???)
10.Only Session Beans and Message driven beans can be designed to use Bean Managed Transaction demarcation.
Entity beans can only be designed to use Container Managed Transaction demarcation.
11.getRollbackOnly() and setRollbackOnly() should be ONLY invoked from methods having Required, RequiresNew,
Mandatory attribute. Otherwise it throws an IllegalStateException.
12.The Enterprise JavaBeans architecture supports FLAT transactions.
A flat transaction cannot have any child (nested) transactions.
13.If an enterprise bean implements the javax.ejb.SessionSynchronization interface, the Application Assembler
can specify only the following values for the transaction attributes of the bean's methods: Required,
RequiresNew,or Mandatory. This restriction is necessary to ensure that the enterprise bean is invoked only
in a transaction.
If the bean were invoked without a transaction, the Container would not be able to send the transaction