Client View of Bean  «Prev 

EJB Home's create() Methods

Home's create() methods


EJB Home's create() methods
EJB Home's create() methods

  1. interface HelloHome extends EJBHome: Home objects implement interfaces that always extend javax.ejb.EJBHome.
  2. Hello create(): Creates the bean instance with a default state and returns a remote reference to the bean's EJBObject instance.
  3. Hello create(String arg1): Creates a bean instance using the specified parameters to set the initial state rather than the default state.
  4. CreateException, RemoteException: The create methods must throw both these exceptions.

Exceptions and EJB

Every networked object in EJB conforms to the RMI-IIOP standard and must throw a remote exception. Thus, every method in an EJB object and home object (such as our hello() method) must throw a remote exception. When such an exception is thrown, it indicates a special error condition such as a
  1. network failure,
  2. machine failure.
But how can your beans throw exceptions that indicate regular, run-of-the-mill problems, such as bad parameters passed to a business method? EJB comes with some built-in exceptions to handle this, and it also allows you to define your own exception types.
More formally, EJB defines the following exception types:
  1. A system-level exception is a serious error that involves some critical failure, such as a database malfunction.
  2. An application-level exception is a more routine exception, such as an indication of bad parameters to a method or a warning of an insufficient bank account balance to make a withdrawal. For example, in our Hello, World! home interface, we throw a standard javax.ejb.CreateException from home interface’s create() method. This is an example of a required applicationlevel exception, indicating that some ordinary problem occurred during bean initialization.

Developing Middleware in Java EE 8
Why must we separate the concepts of system-level and application-level exceptions? The chief reason is that system-level exceptions are handled quite differently from application-level exceptions.
For example, system-level exceptions are not necessarily thrown back to the client. Remember that EJB objects, the container-generated wrappers for beans, are middlemen between a bean’s client and the bean itself. EJB objects have the ability to intercept any exceptions that beans may throw. This allows EJB objects to pick and choose which exceptions the client should see. In some cases, if a bean fails, it may be possible to salvage the client's invocation and redirect it to another bean. This is known as transparent fail-over, a quality of service that some EJB container/server vendors provide. This is an easy service to provide for stateless beans because there is no lost state when a bean crashes. Some highend EJB products even provide transparent fail-over for stateful beans by routinely checkpointing the stateful bean's conversational state .
In case of a critical, unrecoverable problem, your EJB container may support professional monitoring systems, alerting a system administrator if a catastrophic error occurs.
By way of comparison, application-level exceptions should always be thrown back to the client. Application-level exceptions indicate a routine problem, and the exception itself is valuable data that the client needs. For example, we could notify a client of insufficient funds in a bank account by throwing an applicationlevel exception. The client would always want to know about this because it is an application-level problem, not a system-level problem.
Besides correctly routing 1) system-level and 2) application-level exceptions, the EJB object is responsible for catching all unchecked exceptions that your bean may throw, i.e. NullPointer exception which are typically not caught by code. Exceptions that are unchecked in the bean could leave the bean in an abnormal state because the bean is not expecting to handle such an exception. In this scenario, the EJB container intercepts the exception and performs some action, such as throwing the exception back to the client as a remote exception. It also probably stops using that bean because the bean is in an undefined state.
The following two rules of thumb should help you with exceptions.
  1. Application-level exceptions are always thrown back to the client. This includes any exception the bean defines. It also includes the javax.ejb. CreateException for creating beans
  2. When system-level exceptions occur, the EJB container can do anything it wants to: page a system administrator with an alert, send an email to a third party, or throw the exception back to the client. Your bean can throw a system-level exception as either an RMI-IIOP remote exception or an unchecked RuntimeException. If the exception is thrown to the client, it is always thrown as a remote exception or a subclass of it.