81.OK, so EJB doesn’t support user-created threads. So how do I perform tasks asynchronously?

If your EJB does not need to know about the results of the aynch calls, then you can use JMS to send an asynch. message to another part of the system. Another alternative is to place the multithreaded code inside a CORBA or RMI server and call this from your EJB. Always keep site of the big picture, RMI and CORBA are part of J2EE and can be used as part of a ‘J2EE’ solution. There are some things that these technologies can do that EJB at this present time cannot.

82.What is an EJB Context?

EJBContext is an interface that is implemented by the container, and it is also a part of the bean-container contract. Entity beans use a subclass of EJB Context called EntityContext. Session beans use a subclass called SessionContext. These EJBContext objects provide the bean class with information about its container, the client using the bean and the bean itself. They also provide other functions. See the API docs and the spec for more details

83.Can I deploy a new EJB without restarting my server? (I’m using Weblogic.)

Sure. WebLogic Server4.5 includes “hot deploy” feature that allow you to deploy, redeploy or undeploy EJBs while the Server is running, from the Weblogic Console. Deployment of EJBs made through the console are however lost when you restart the WebLogic Server.

84.How to setup access control in an EJB such that different application clients have different rights to invoke different methods in one EJB?

• Set up the different users/groups and the methods each can have access to in your deployment descriptor. Note: You don’t have to specify different methods for each user, you could also just specify different users to your entire bean – for example if you only wanted another component of your application talking to your bean.
• Inside your client code, whenever you make your connection to the EJB server (to look up the bean) you need to specify the user and password, in order to set the Identity of the client:

1 ... Properties p =newProperties();
2 .. p.put(Context.SECURITY_PRINCIPAL,"user");
3 p.put(Context.SECURITY_CREDENTIALS,"password"); ...

• Inside your bean, you can do “extra” security checks (if you used ‘Role’-based security): (Assuming you have a ‘manager’ role defined in your deployment descriptor and a user assigned to this role)

1 publicintgetAccountBalance(accountId)
2 {if(ejbContext.isCallerInRole("manager"))returnbalance; }
You could also enforce security to your EJB server. Using Weblogic, you could add the following to your weblogic.properties file:
1 ... weblogic.password.user=password ...
where “user” is the username you grant access for and “password” (after ‘=’) is the password for this username

85.How is persistence implemented in enterprise beans?

Persistence in EJB is taken care of in two ways, depending on how you implement your beans: container managed persistence (CMP) or bean managed persistence (BMP). For CMP, the EJB container which your beans run under takes care of the persistence of the fields you have declared to be persisted with the database – this declaration is in the deployment descriptor. So, anytime you modify a field in a CMP bean, as soon as the method you have executed is finished, the new data is persisted to the database by the container. For BMP, the EJB bean developer is responsible for defining the persistence routines in the proper places in the bean, for instance, the ejbCreate(), ejbStore(), ejbRemove() methods would be developed by the bean developer to make calls to the database. The container is responsible, in BMP, to call the appropriate method on the bean. So, if the bean is being looked up, when the create() method is called on the Home interface, then the container is responsible for calling the ejbCreate() method in the bean, which should have functionality inside for going to the database and looking up the data.

86.Can the primary key in the entity bean be a Java primitive type such as int?

The primary key can’t be a primitive type–use the primitive wrapper classes, instead. For example, you can use java.lang.Integer as the primary key class, but not int (it has to be a class, not a primitive).

87.How do I map a Date/Time field to an Oracle database with CMP?

[Question continues: (I have written a wrapper class with the help of java.util.GregorianCalendar but it doesn’t store time in Oracle database, whereas it stores Date without any problem.)]
Use the java.sql.Timestamp field to store your Date/Time in your entity bean, and then declare the corresponding field as ‘Date’ type in the Oracle database and it will work fine. You will have the “date” value and the “time” value preserved.

88.What is the difference between a Server, a Container, and a Connector?

To keep things (very) simple: An EJB server is an application, usually a product such as BEA WebLogic, that provides (or should provide) for concurrent client connections and manages system resources such as threads, processes, memory, database connections, network connections, etc.
An EJB container runs inside (or within) an EJB server, and provides deployed EJB beans with transaction and security management, etc. The EJB container insulates an EJB bean from the specifics of an underlying EJB server by providing a simple, standard API between the EJB bean and its container.
(Note: The EJB 1.1 specification makes it clear that it does not architect the interface between the EJB container and EJB server, which it says it left up to the vendor on how to split the implementation of the required functionality between the two. Thus there is no clear distinction between server and container.) A Connector provides the ability for any Enterprise Information System (EIS) to plug into any EJB server which supports the Connector architecture.

89.What is “clustering” in EJB?

Clustering refers to the ability of multiple load-balanced web servers to share session and entity data. It is a major feature of web application servers. Standardized support for clustering was one of the primary motivations behind the EJB spec.
Clustering also applies to Servlet containers sharing HttpSession data (similar to EJB Session Beans).

90.What is “hot deployment” in WebLogic?

“Hot Deployment” in weblogic is the act of deploying, re-depolying, and un-deploying EJBs while the server is still running (you don’t have to shutdown the server to deploy an EJB).

91. Can I specify specific WHERE clauses for a find method in a CMP Entity Bean?

The EJB query language is totally vendor specific in EJB1.1. It is being standardized in 1.2. Yes, you can specify the where clause for a find method. This is the example for EJB’s deployed on weblogic:
1.findBigAccounts(doublebalanceGreaterThan):
2."(> balance $balanceGreaterThan)"
where balance maps to some field in the table.

92.When using a stateful session bean with an idle timeout set, how can the bean receive notification from the container that it is being removed due to timeout?

(Through some tests, it looks like none of the standard EJB callback methods are called when a stateful session bean is removed due to idle-timeout.)]
According to the spec, ejbRemove need not (or must not) be called in this case. ejbPassivate is simply the Wrong Thing to be called (the bean is transitioning to the ‘does not exist’ state, not the ‘passive’ state). The EJB 1.1. spec says in section 6.6.3 Missed ejbRemove Calls:

• The application using the session bean should provide some clean up mechanism to periodically clean up the unreleased resources.
• For example, if a shopping cart component is implemented as a session bean, and the session bean stores the shopping cart content in a database, the application should provide a program that runs periodically and removes “abandoned” shopping carts from the database.

Probably not the answer you’re looking for, especially if you allocate some other resource (a Message Queue, for example) that you need to release. Although, if you’re using a resource, you really should be getting it when you need it (via JNDI) and returning it back to the pool right away.

93.I have created a remote reference to an EJB in FirstServlet. Can I put the reference in a servlet session and use that in SecondServlet?

Yes.
The EJB client (in this case your servlet) acquires a remote reference to an EJB from the Home Interface; that reference is serializable and can be passed from servlet to servlet. If it is a session bean, then the EJB server will consider your web client’s servlet session to correspond to a single EJB session, which is usually (but not always) what you want.

94.What is the difference between a Component Transaction Monitor (CTM) and an Application Server?

A Component Transaction Monitor (CTM) is an application server that uses a server-side component model. Since a CTM is a Transaction Processing monitor (TP), it is expected to provide services for managing transactions, security, and concurrency. In addition, CTMs also facilitate distributed object architectures and provide facilities for object persistence. In short, a CTM is a specific type of application server

95.How can I call one EJB from inside of another EJB?

Just do it!
EJBs can be clients of other EJBs. It just works. Really. Use JNDI to locate the Home Interface of the other bean, then acquire an instance reference, and so forth.

96.When using Primary Keys, why do I have to implement the hashCode() and equals() method in my bean?

Implementing the hashCode() and equals() functions ensure that the primary key object works properly when used with hash tables. Hash tables are the preferred way EJB servers use to store and quickly retrieve instantiated entity beans.
If session #1 uses widget “A” (which is an entity bean) then the server needs to do some work to instantiate and initialize the object. If session #2 then requests the same widget “A”, the EJB server will look in its hash table of existing entity beans of type widget to see if widget “A” has already been instantiated

97.Can I deploy two beans in a single jar file? If so, how?

Yes, multiple EJBs can be deployed in a single jar file. The deployment is somewhat different between EJB 1.0 and EJB 1.1. In EJB 1.1 and in the draft EJB 2.0 specification, instead of a manifest and serialized deployment descriptors there is a single shared XML deployment descriptor named META-INF/ejb-jar.xml. Within ejb-jar.xml there must be either a or element for each bean in the jar file. For example, the following XML fragment is for a jar file that contains one entity and one session bean:
1 <ejb-jar> <enterprise-beans>
2 <session> <ejb-name>MySessionBean</ejb-name>
3 ... other xml elements describing the bean's deployment properties ...
4 </session> <entity> <ejb-name>MyEntityBean</ejb-name> ...
5 other xml elements describing the bean's deployment properties ...
6 </entity> </enterprise-beans> </ejb-jar>
The EJB 2.0 draft specification for deployment descriptors differs from EJB 1.1 only in the addition of XML elements for describing additional bean properties.

98.Why use EJB when we can do the same thing with servlets?

Actually, servlets/JSPs and EJB are complementary, not competing technologies: Servlets provide support for writing web based applications whereas EJBs provide support for writing transactional objects. In larger web systems that require scalability, servlet and JSP or XML/XSL technologies provide support for the front end (UI, client) code, where EJB provides support for the back end (database connection pooling, declaritive transactions, declaritive security, standardized parameterization…) The most significant difference between a web application using only servlets and one using servlets with EJBs is that the EJB model mandates a separation between display and business logic. This is generally considered a Good Thing in non-trivial applications because it allows for internal reuse, allows flexibility by providing a separation of concerns, gives a logical separation for work, and allows the business logic to be tested separately from the UI (among others). Some of the hings that servlets and JSPs can do that EJBs cannot are:

• Respond to http/https protocol requests.
• (With JSP) provide an easy way to format HTML output.
• Easily associate a web user with session information Some of the things that EJBs enable you to do that servlets/JSPs do not are:

• Declaritively manage transactions. In EJB, you merely specify whether a bean’s methods require, disallow, or can be used in the context of a transaction. The EJB container will manage your transaction boundaries appropriately. In a purely servlet architecture, you’ll have to write code to manage the transaction, which is difficult if a logical transaction must access multiple datasources.
• Declaritively manage security. The EJB model allows you to indicate a security role that the user must be assigned to in order to invoke a method on a bean. In Servlets/JSPs you must write code to do this. Note, however that the security model in EJB is sufficient for only 90% to 95% of application code – there are always security scenarios that require reference to values of an entity, etc.

99.What restrictions are imposed on an EJB? That is, what can’t an EJB do?

From the spec:

• An enterprise Bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final.
• An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances.
• An enterprise Bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.
• An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.
• An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.
• The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language. The enterprise bean must not attempt to use the Reflection API to access information that the security rules of the Java programming language make unavailable.
• The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.
• The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.
• The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread; or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.
• The enterprise bean must not attempt to directly read or write a file descriptor.
• The enterprise bean must not attempt to obtain the security policy information for a particular code source.
• The enterprise bean must not attempt to load a native library.
• The enterprise bean must not attempt to gain access to packages and classes that the usual rules of the Java programming language make unavailable to the enterprise bean.
• The enterprise bean must not attempt to define a class in a package.
• The enterprise bean must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity).
• The enterprise bean must not attempt to use the subclass and object substitution features of the Java Serialization Protocol.
The enterprise bean must not attempt to pass this as an argument or method result. The enterprise bean must pass the result of SessionContext.getEJBObject() or EntityContext. getEJBObject() instead.

100.Why do we have a remove method in both EJBHome and EJBObject?

With the EJBHome version of the remove, you are able to delete an entity bean without first instantiating it (you can provide a PrimaryKey object as a parameter to the remove method). The home version only works for entity beans. On the other hand, the Remote interface version works on an entity bean that you have already instantiated. In addition, the remote version also works on session beans (stateless and statefull) to inform the container of your loss of interest in this bean.

---