Java Enterprise and Web Technologies

Technically yes, you can use a constructor for servlet initialization. However, the servlet specification recommends using init() because: (1) ServletConfig is not available in the constructor, (2) init() is called after the container completes initialization. Using constructor is possible but not standard practice.

ServletContext attributes are stored in the JVM memory of a single container instance. In a distributed (clustered) web application, different JVMs run independently, so ServletContext attributes cannot be shared across them. Database, EJBs, and clustered HttpSessions can span JVMs.

Technically, the destroy() method of a servlet is a public method and can be invoked manually from any method, including service(). However, doing so does not unload the servlet; it only executes the logic inside the destroy method, which is generally bad practice.

The page implicit object is synchronized because it is a reference to the current servlet instance (this). In JSP, the page object represents the servlet itself, and the servlet instance is typically synchronized by the container to handle concurrent requests safely.

For sendRedirect(), you must use encodeRedirectURL(). The encodeURL() method is for regular URLs (links in HTML, form actions). encodeRedirectURL() specifically handles the session encoding rules required for redirect responses.

If a transaction is initiated by a client (Required attribute) and the bean method throws a system (unchecked) exception, the EJB container intercepts it, rolls back the transaction, and throws a TransactionRolledBackException to the client. Checked exceptions do not cause auto-rollback by default.

To maintain client state, the user needs to know the different options available and which option is best suited to the given scenario.

A. Cookies: Cookies are small text files that are stored on the client's computer. They can be used to store client state information, such as user preferences or session IDs. While cookies can be effective for maintaining state, they have some limitations, such as a limited storage capacity and the potential for security vulnerabilities.

B. Entity Beans: Entity beans are used to represent persistent data in a Java Enterprise Edition (JEE) application. They are not designed to maintain client state.

C. HttpSession attributes: HttpSession attributes are used to store client-specific information on the server side. They are associated with a particular user session and can be used to maintain client state across multiple requests. This makes HttpSession attributes a good option for maintaining client state in a JEE application.

D. Stateful session beans: Stateful session beans are designed to maintain state across multiple requests. They are associated with a particular client and can be used to store client-specific information. This makes stateful session beans a good option for maintaining client state in a JEE application.

E. URL Rewriting: URL rewriting is a technique for adding session IDs to URLs. This allows the server to identify the client and maintain state across multiple requests. While URL rewriting can be effective for maintaining state, it has some limitations, such as the potential for security vulnerabilities and the impact on URL readability.

Based on the given scenario, the best option for maintaining client state is D. Stateful session beans, as they are designed to maintain state across multiple requests and are associated with a particular client. Option C. HttpSession attributes is also a good option since it can be used to maintain client state across multiple requests. Option A. Cookies and option E. URL Rewriting can also be used to maintain state but are less suited to the given scenario.

The Answer is: D. Stateful session beans

Message Driven Beans (MDBs) do not have client view interfaces (local or remote) because they do not receive direct synchronous calls from clients; instead, they act as asynchronous message consumers listening to JMS queues or topics.

The SessionFacade pattern hides complexity, provides a simple interface, and reduces network traffic by consolidating remote calls. However, it manages transactions on the server side; allowing the client to control fine-grained transactions contradicts the pattern's goal of abstraction.

When you use only the type attribute in jsp:useBean (without class or beanName), the container will look for an existing bean with the specified scope and type. If no existing bean is found, no new instance is created. This prevents instantiation when you only want to reference existing beans.

In a unidirectional one-to-many CMR relationship where A owns the relationship to B, only bean A's local interface exposes the relationship methods (abstract getter/setter for the collection of B). Bean B has no knowledge of the relationship in unidirectional CMR.

In bean-managed transactions (BMT), stateful session beans manage their own transactions using UserTransaction methods. The getRollbackOnly() method is specific to container-managed transactions (CMT) and is not available in BMT context. getUserTransaction() and getStatus() are valid methods that can be called in BMT.