--------------------------------------------------
SESSION BEANS
--------------------------------------------------

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
create<METHOD>.

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.


18. 7.10.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.