Which two statements are correct about stateless session beans?

Which two statements are correct about stateless session beans? (Choose two.)

A.
The bean class may declare instance variables.

B.
The lifetime of the bean instance is controlled by the client.

C.
The container may use the same bean instance to handle multiple business method invocations
at the same time.

D.
The container may use the same bean instance to handle business method invocations
requested by different clients, but not concurrently.

Explanation:
* A: Stateless session beans are EJB’s version of the traditional transaction
processing applications, which are executed using a procedure call. The procedure executes from
beginning to end and then returns the result. Once the procedure is done, nothing about the data
that was manipulated or the details of the request are remembered. There is no state.
These restrictions don’t mean that a stateless session bean can’t have instance variables and
therefore some kind of internal state. There’s nothing that prevents you from keeping a variable
that tracks the number of times a bean has been called or that tracks data for debugging. An
instance variable can even hold a reference to a live resource like a URL connection for writing
debugging data, verifying credit cards, or anything else that might be useful.
C:A stateless session bean is relatively easy to develop and also very efficient. Stateless session
beans require few server resources because they are neither persistent nor dedicated to one
client. Because they aren’t dedicated to one client, many EJB objects can use just a few instances
of a stateless bean. A stateless session bean does not maintain conversational state relative to
the EJB object it is servicing, so it can be swapped freely between EJB objects. As soon as a
stateless instance services a method invocation, it can be swapped to another EJB object
immediately. Because there is no conversational state, a stateless session bean doesn’t require
passivation or activation, further reducing the overhead of swapping. In short, they are lightweight
and fast!
*
The Lifecycle of a Stateless Session Bean
Because a stateless session bean is never passivated, its lifecycle has only two stages:
nonexistent and ready for the invocation of business methods.
The EJB container typically creates and maintains a pool of stateless session beans, beginning
the stateless session beans lifecycle. The container performs any dependency injection and then
invokes the method annotated @PostConstruct, if it exists. The bean is now ready to have its
business methods invoked by a client.
At the end of the lifecycle, the EJB container calls the method annotated @PreDestroy, if it exists
(not B). The beans instance is then ready for garbage collection.