Enterprise Java Beans (EJB) Architecture

In EJB (Enterprise JavaBeans), ejbLoad() is a callback method specific to Entity beans that is invoked by the container to synchronize the bean's state with the underlying database. This method is called when the container needs to refresh the entity bean's state from persistent storage.

MessageDrivenBeans in EJB cannot have local or remote interfaces because they are designed to process asynchronous messages via JMS (Java Message Service). Unlike session or entity beans, MessageDrivenBeans are implemented as message listeners and are not intended for direct client invocation through business interfaces.

The @PrePassivate annotation in EJB indicates a callback method that is invoked before a stateful session bean is passivated (temporarily serialized to secondary storage). Like other lifecycle callback methods such as @PostConstruct and @PreDestroy, it must return void and throw no checked exceptions.

Stateful session beans in EJB undergo all these lifecycle transitions: construction (when created), destruction (when removed), activation (when restored from secondary storage), and passivation (when temporarily serialized). These callbacks allow the bean to manage its state through the complete lifecycle.

The Application Assembler is responsible for assembling enterprise beans into application modules and can override transaction attributes defined by the Bean Provider. The Deployer then deploys these assembled modules, while System Administrators manage runtime resources. The Bean Provider only defines default transaction attributes.

To solve this question, the user needs to understand the basics of entity beans and their primary keys.

A) Every entity must have a primary key. This statement is true as the primary key is used to uniquely identify each entity bean in the database. Without a primary key, it would be impossible to distinguish between different instances of the same entity.

B) It is not necessary to define a primary key for an Entity. This statement is false. As mentioned above, every entity must have a primary key. It is not optional.

C) @Primary annotation is used for denoting a simple primary key. This statement is false. @Primary annotation is not a built-in annotation in Java Persistence API (JPA). Instead, the @Id annotation is used to denote a primary key.

D) Option B is incorrect. Therefore, the correct answer is:

The Answer is: A

EJB architecture defines a distributed component-based architecture for building enterprise business applications. It provides services like transaction management, security, and persistence while allowing developers to focus on business logic. EJB is Java-specific (not language-independent) and predates Web Services, being built on RMI-IIOP, not Web Services architecture.

Container-Managed Transactions (CMT) can be used with both Session and Entity Beans. However, Bean-Managed Transactions (BMT) are strictly prohibited for Entity Beans by the Enterprise JavaBeans specification. Entity Beans must always use CMT. Therefore, the statement is false.

In EJB specifications, the lifecycle states of a Stateless Session Bean are limited to 'Does not exist' and 'Method-ready pool' (or 'Pooled'). Among the choices, 'Does not exist' is the standard lifecycle state. 'Passive' only applies to stateful session beans during passivation.

Server clusters provide high availability and scalability in EJB environments by distributing incoming requests across multiple servers. This load distribution prevents any single server from becoming a bottleneck and allows the system to continue functioning even if one server fails. The load balancing capability ensures optimal resource utilization and improved performance. Location transparency, caching, and 2PC are separate concepts not directly related to clustering benefits.

In EJB deployment descriptors, the 'NEVER' transaction attribute explicitly indicates that the method must never be executed within a transaction context. 'NOT_SUPPORTED' allows the method to run outside a transaction but doesn't forbid it if one exists. 'NO_TRANSACTIONS' is not a valid EJB transaction attribute. The default is 'Required' for CMT beans, not empty.

For Container-Managed Transactions (CMT), the default transaction attribute is 'Required', meaning the method must always execute within a transaction. If none exists, the container creates one. NotSupported, RequiresNew, and Supports are all valid attributes but must be explicitly specified - they are not defaults.

All four statements are true for composite primary keys in EJB: the primary key class must be Serializable to be persisted, its value must not change after entity creation (it's immutable), properties must be public or protected for container access, and the class itself must be public. Option E correctly captures this.

Stateful session beans support all four callback types: construction (PostConstruct), destruction (PreDestroy), activation (PostActivate), and passivation (PrePassivate). These lifecycle events allow the container to manage bean state when passivating to secondary storage or activating back into memory.

Stateless session beans only support two lifecycle callbacks: PostConstruct (after creation) and PreDestroy (before removal). They don't support activation/passivation because they don't maintain conversational state - instances are pooled and interchangeable.

The lifecycle methods for Stateful Session Beans are: PostConstruct (after creation), PreDestroy (before removal), PostActivate (after passivation), and PrePassivate (before passivation). There is no 'Pre Construction' lifecycle method - construction happens before PreConstruct, not after. PreConstruction would imply something happens before the bean exists, which is impossible.

Once a thread completes execution (dies), it cannot be restarted. The Thread class's start() method can only be called once per thread instance. Attempting to restart a dead thread throws an IllegalThreadStateException. You must create a new Thread instance to run the task again.

To solve this question, the user needs to have knowledge about the concept of threads in Java and how to create a thread using a Runnable target.

The correct answer is:

C. public class MyRunnable implements Runnable{public void run(){}}

Explanation:

In the given code, we are creating a thread using a Runnable target. The Runnable interface provides a way to implement multi-threading in Java by defining a run() method that will be executed in a separate thread.

To create the target, we need to implement the Runnable interface by providing a definition for the run() method. Option C correctly implements the Runnable interface with a run() method, so it is the correct answer.

Option A is incorrect because it extends the Runnable interface without providing a definition for the run() method.

Option B is incorrect because it extends the Object class and does not implement the Runnable interface.

Option D is incorrect because it implements the Runnable interface but does not provide the run() method with the correct signature (i.e., it should be public void run()).

Therefore, the correct answer is:

The Answer is: C