JAVA SERVER SIDE/ J2EE(SERVLETS/ JSP /RMI/EJB/JMS)

SERVLETS

Q. How do you communicate between applet and servlet?

Answer: Through Http Tunneling
Q. What is the use of servlets?

Answer: The Servlets are server side java programs, which are used to generate dynamic web content for a web clients. They reside inside a servlet container on a web server or an application server. The servlet container provides them a runtime environment.
Q. How will you pass values from HTML to the servlet?

Answer: The values from an HTML page are passed to a servlet either through a GET or POST method. In a servlet, request.getParameter (“strParam”) method is called in order to retrieve values from HTML form to a servlet end where String strParam represents the name of the input type OR values can be passed concatenated with URL itself which request the servlets receive.
Q. What is the difference between CGI and servlets?

Answer: In traditional CGI, a new process is started with each client request and this will correspond to initiating a heavy OS level process each time when a client request comes. While in case of servlets JVM handles client requests at a web server end and each client request correspond to thread which consumes less resources as compared with CGI process, thus making CGI inefficient. In Java servlet, there is only a single instance, which answers all requests concurrently. This saves memory and allows a Servlet to easily manage persistent data.
A Java servlet can straightaway talk with a web server while in case of CGI it is not possible unless server specific API have not been used.
Java servlets are portable and inexpensive.
Java servlets resides in Servlet engine and are executed within sandbox making it more secure and robust.
Q. What is client server computing?

Answer: The client server computing means expediting a client’s requests through a remotely located server. A client accesses a remote server through an interface (may be an application or browser based client interface) using web related technologies specific to several vendors viz. Microsoft, Sun, OMG etc.
Q. What is a middleware and what is the functionality of Webserver?

Answer: A middleware in a 3-tier architecture sits in the middle of a client’s machine and a database server. A middleware is where all the business related logic resides and it is also known as Web Application Server. (e.g. WebLogic from BEA, WebSphere from IBM, Oracle 9iAS from Oracle etc.)In distributed programming divide and rule is the name of the game and in this paradigm a middleware has a good share of responsibilities viz. load balancing, database connection pooling, security, transaction management related services, web and enterprise component deployment services, content management related services etc.
Q. What is meant by Session tell me something about HttpSession?

Answer: A web client makes a request to a web server over HTTP. As long as a client interacts with the server through a browser on his or her machine is called as session. HTTP is a stateless protocol. A client’s each request is treated as a fresh one with no info of client to the server and the moment browser is closed, session is also closed. In an online shopping or web cart kind of application where session related information is critical for successive purchases made by a client, there have been suggested several techniques for session tracking in Java Servlets as mentioned below:• Hidden form fields• URL Rewriting• Cookies• HttpSession objectHttpSession is an interface, which belongs to javax.servlet.http. * package This provides a facility to identify a user across the several pages’ requests.Looking up the HttpSession object associated with the current request.This is done by calling the getSession method of HttpServletRequest. If this returns null, you can create a new session, but this is so commonly done that there is an option to automatically create a new session if there isn't one already. Just pass true to getSession. Thus, your first step usually looks like this: HttpSession session = request.getSession (true);
Q. How do you invoke servlets what is the difference in between doGet and doPost?

Answer:
1) Servlets can be explicitly accessed with the URL:
http://server:8080/servlet/ServletName
where server is the name of the server or localhost if the server is running on your local machine and ServletName is the name of your servlet class name.
2) Run the web server administration tool and associate an arbitrarily chosen name with the servlet class name. This name is sometimes called the "registered" servlet name. For example, you could associate "MyName" with your servlet class name and you would invoke the servlet with the URL:
http://server:8080/servlet/MyName
3) Run the web server administration tool and set up an alias for a URL so that when that when that URL is accessed, a specific servlet is invoked. For example, you can alias the following URL to invoke a servlet:
http://server:8080/anyurl
Aliases are useful if you’re replacing existing HTML pages with servlets. You can keep the URLs the same; they’ll invoke servlets instead of displaying the HTML.
Difference between doGet and doPost Sending a GET or POST request to it in order to expedite the request by calling corresponding doGet() and doPost() methods.
doGet is called in response to an HTTP GET request. This happens when users click on a link, or enter a URL into the browser's address bar. It also happens with some HTML FORMs (those with METHOD="GET" specified in the FORM tag). doPost is called in response to an HTTP POST request. This happens with some HTML FORMs (those with METHOD="POST" specified in the FORM tag).
Both methods are called by the default (superclass) implementation of service in the HttpServlet base class. You should override one or both to perform your servlet's actions. You probably shouldn't override service().
There is a restriction of numbers of parameters to be sent through doGet method around 2k of data can be sent and moreover whole of URL is to be mentioned in case of doGet as mentioned below:http://www.spearheadit.com/servlet?param1=value1&param2=value2&...&paramN=valueNSo it is always better to use doPost() when sending parameters from a FORM as it doesn’t show off information related with password on the network etc.
Q. What is the difference between GenericServlet and HTTPServlet? Explain their methods? Tell me their parameter names also?

Answer: HTTPServlet class extends GenericServlet class. GenericServlet class helps in creating servlets, which are protocol independent.GenericServlet has a serve() method aimed to handle requests. HttpServlet extends GenericServlet and adds support for doGet(), doPost(), doHead() methods (HTTP 1.0) plus doPut(), doOptions(), doDelete(), doTrace() methods (HTTP 1.1). Both these classes are abstract.
Q. Can there be more than one instance of a servlet at one time ?

Answer: It is important to note that there can be more than one instance of a given Servlet class in the servlet container. For example, this can occur where there was more than one servlet definition that utilized a specific servlet class with different initialization parameters. This can also occur when a servlet implements the SingleThreadModel interface and the container creates a pool of servlet instances to use.
Q. What is SingleThreadModel in view of servlets?

Answer: SingleThreadModel interface once implemented makes a servlet thread safe. In this case only one thread will be able to execute service() method at a time.Though it affects the performance of the servlet to a great extent. In STM container creates multiple instances of servlet
Q. Why there are no constructors in servlets?

Answer: A servlet is just like an applet in the respect that it has an init() method that acts as a constrcutor. Since the servlet environment takes care of instantiating the servlet, an explicit constructor is not needed. Any initialization code you need to run should be placed in the init() method since it gets called when the servlet is first loaded by the servlet container.
Q. What is the difference in between encodeRedirectURL and encodeURL?

Answer: encodeURL and encodeRedirectURL are methods of the HttpResponse object. Both rewrite a raw URL to include session data if necessary. (If cookies are on, both are no-ops.) encodeURL is for normal links inside your HTML pages.
encodeRedirectURL is for a link you're passing to response.sendRedirect().
Q. What do Cookies mean? Explain.

Answer: Cookies are information text messages exchange between a client and server in order to keep a track of session of a user to a server. Cookies help a user in order to reconnect to a site on later date, as textual information is stored at the client end for max age of the cookie.
Q. Why do GenericServlet and HttpServlet implement the Serializable interface? Answer: GenericServlet and HttpServlet implement the Serializable interface so that servlet engines can "hybernate" the servlet state when the servlet is not in use and reinstance it when needed or to duplicate servlet instances for better load balancing. I don't know if or how current servlet engines do this, and it could have serious implications, like breaking references to objects gotten in the init() method without the programmer knowing it. Programmers should be aware of this pitfall and implement servlets which are stateless as possible, delegating data store to Session objects or to the ServletContext. In general stateless servlets are better because they scale much better and are cleaner code.
Q. Why do we need to call super.init(config) in the init method of a servlet?

Answer: The reason is Servlet interface defines a method called getServletConfig(),you should either save the servletconfig object and implement the getServletConfig()method yourself or pass the object to the parent class using super.init(). However this is done for backward compatibility(before version 2.1).In version 2.1 you don't require to call that super.init()
Q. Can you use System.exit in your servlet end code?

Answer: No At best, you'll get a security exception.At worst, you'll make the servlet engine, or maybe the entire web server, quit.
Q. What is a Servlet Context?

Answer: A Servlet Context is a group where related servlets (and JSPs and other web resources) run. They can share data, URL namespace, and other resources. There can be multiple contexts in a single servlet container. The ServletContext object is used by an individual servlet to "call back" and obtain services from the container (such as a request dispatcher).

Q. What is the difference between Java Servlets and Java ServerPages (JSP)? Answer:

Short answer: a JSP is a Servlet that thinks it's a Web page.

Medium answer: Both use server-side Java to dynamically generate web pages. The source code to a servlet looks like Java, with HTML embedded in out. print (...) statements. Both use the Servlet API to communicate with the web server and the client. In fact, a JSP gets compiled into a servlet, so they're almost identical in terms of expressive power. The choice is, whether you're more comfortable coding your pages in Java or in JSP-style HTML; and since you can call a JSP from a Servlet and vice versa, you don't have to make an either-or decision.

Long answer: See the Servlet FAQ and the JSP FAQ for all the information you need about both technologies.
(*) "Funny tags:" JSP can contain (a) normal HTML tags, (b) JSP tags like , (c) custom tags, (d) scriptlets (Java code surrounded with <% and %>).
Q. What is the difference between page directive <%@include % > and action command?

Answer: JSP directive <%@include %> is interpreted at the compile time and text is merged before JSP being converted into servlet.While in case of is interpreted at the runtime where text is merged with JSP at runtime may be a servlet or a JSP is included at runtime.
Q. What are Entity Bean and Session Bean?

Answer: An Entity Bean is a persistent business data object in a business process, which provides an OR (Object Relational) mapping over an underlying RDBMS.It is transactional in nature. An in memory objects can be mapped with a field of table in RDBMS database.An Entity can be expressed as a Noun e.g. a Customer, a Product, an Account, Purchase Order etc. Entity beans are long lasting as they represent data in the database. Entity beans can be of two types:a. CMP Entity Bean: In case of container managed persistent Entity bean, EJB container manages data persistence and a bean developer do not have to bother about business data persistence logic.
b. BMP Entity Bean: A bean managed persistent entity bean is persisted in the database by hand or say programmatically. A component developer has to code to translate in memory objects to underlying RDBMS or object database.
A Session Bean incorporates business logic or business rules or workflow related logic of an enterprise. A session bean exists only until a session exists between a client and server so it has real short period of its existence. Session beans are of two types: a. Stateless Session BeanIn case where state between a client and a server interaction is not to be persisted then Stateless session bean is to be used. e.g. executing calculating tax or validating a credit card etc. The stateless bean instance does not have longevity.
b. Stateful Session BeanStateful Session bean keeps a conversational state of a client over a series of method calls, keeping it in a persistent area. They are more functional than stateless session bean as they store conversational state.
Whenever a client access a stateful session bean and trough with a series of method calls over it then before moving the bean instance into passivated state, the conversational state is stored into the persistent area i.e. hard disk. This makes smart resource management. Whenever the same client is making a request again over the stateful session bean then state is pulled out of hard disk into in memory of bean. This is called activated state. Thus state of a client is saved in between context switching in a persistent storage area.
Q. What are the methods of Entity Bean?

Answer: The methods of an Entity Bean are enlisted as below:
create methods: These methods are used for creating an instance of an Entity bean .They correspond to ejbCreate() method of bean class and always implemented.
finder methods: These methods are used for locating bean instance based on a unique identifier called primary key. findByPrimaryKey (), which returns a Collection of remote references to bean.
remove methods: These methods (you may have up to 2 remove methods, or don't have them at all) allow the client to physically remove Entity Beans. You can remove these beans by specifying either Handle or a Primary Key for the Entity Bean.
home methods:
Q. How does Stateful Session Bean store its state?

Answer: Whenever a client access a stateful session bean and trough with a series of method calls over it then before moving the bean instance into passivated state, the conversational state is stored into the persistent area i.e. hard disk. This makes smart resource management. Whenever the same client is making a request again over the stateful session bean then state is pulled out of hard disk into in memory of bean. This is called activated state. Thus state of a client is saved in between context switching in a persistent storage area.
Q. Why does Stateless Session bean not store its state even though it has ejbActivate and ejbPassivte?

Answer: Though a Stateless Session Bean has ejbActivate and ejbPassivate but the developers do not implement them in order to make its state persisted as state persistence occurs during a context switch of Session bean when it goes from activated to passivated state and vice versa.
Q. What are the services provided by the container?

Answer: The container provides following services:a. Transaction Managementb. Persistencec. Securityd. Connection Poolinge. Naming services
Q. Types of transaction?

Answer: Simple TransactionsNested TransactionsDistributed Transactions
Q. What is bean-managed transaction?

Answer: When a component developer wishes to handle transaction related issues programmatically it is done through using bean-managed transaction. The bean controls transaction within its boundaries.
Q. Why does EJB need two interfaces (Home and Remote Interface)?

Answer: EJB by design has two interfaces out of which Home interface is responsible for lifecycle management of EJB and other one a Remote interface is responsible for exposing business methods to rest of the world. This is done in order to segregate the responsibilities one to create/find/remove a remote bean and another one to expose business methods of bean through a remote interface.
Q. What are transaction attributes?

Answer: Transaction Attribute DescriptionRequired RequiresNew Manadatory Supports Never NotRequired.
Q. What is the difference between CMP and BMP Entity Bean?

Answer: The major difference between CMP and BMP Entity Beans is managing persistence of data through container in case of CMP and programmatically in BMP.Generally, you should use CMP unless you're forced to use BMP due to limitations of the mapping tools. In case of mapping some relatively complex data models.CMP is better than BMP as far as performance is concerned as in case of CMP through OR mapping optimization of transaction process is taken care off by container in the best possible manner. While in case of BMPs you can optimize your queries and improve performance over the generalized container-managed heuristics.
Q. What is J2EE?

Answer: J2EE is a server side component based distributed architecture meant to build enterprise level solutions addressing to complex business process requirements.J2EE is an assembly of several Java technologies enlisted as given below:• Java Servlets• JSP• EJB• JNDI• JTA/JTS• JMS• JDBC• Java Mail APIs• RMI• Java-XML• Java IDL
Q. What is JTS?

Answer: JTS is Transaction related services and it specifies the implementation of a Transaction Manager, which supports the Java Transaction API (JTA) 1.0 Specification at the high-level and implements the Java mapping of the OMG Object Transaction Service (OTS) 1.1 Specification at the low-level. JTS uses the standard CORBA ORB/TS interfaces and Internet Inter-ORB Protocol (IIOP) for transaction context propagation between JTS Transaction Managers.
A JTS Transaction Manager provides transaction services to the parties involved in distributed transactions: the application server, the resource manager, the standalone transactional application, and the Communication Resource Manager (CRM).
Q. Which transaction attributes should I use in which situations?

Answer: The following are some of the points to be remembered when specifying transaction attributes for Enterprise JavaBeansTM-technology based components (EJBTM):
All methods of a session bean's remote interface (and super interfaces) must have specified transaction attributes. Session bean home interface methods should not have transaction attributes. (All methods of an entity bean's remote and home interfaces (and super interfaces) must have specified transaction attributes, with the exception of: methods getEJBHome(), getHandle(), getPrimaryKey(), isIdentical() methods of the remote interface; and methods getEJBMetaData(), getHomeHandle() of the home interface. Use Required as the default transaction attribute, to ensure that methods are invoked within a Java Transaction API (JTA) transaction context. Required causes the enterprise bean to use existing transactional context if it exists, or to create one otherwise.
Use RequiresNew when the results of the method must be committed regardless whether the caller's transaction succeeds. For example, a method that logs all attempted transactions, whether those transaction succeed or not, could use RequiresNew to add log entries. RequiresNew always creates a new transaction context before the method call, and commits or rolls back after the method call. Note that any existing client transaction context will be suspended until the method call returns.
Use Supports for methods that either do not change the database (directly or indirectly); or update atomically, and it does not matter whether or not the update occurs within a transaction. Supports uses the client transaction context if it exists, or no transaction context otherwise.
Use Mandatory when the method absolutely requires an existing transaction. Mandatory causes RemoteException to be thrown unless the client is associated with a transaction context.
Use Never to ensure that a transactional client does not access methods that are not capable of participating in the transaction. Never causes RemoteException to be thrown if the client is associated with a transactional context.
Use NotSupported when an enterprise bean accesses a resource manager that either does not support external transaction coordination, or is not supported by the J2EE product. In this case, the bean must have container-managed transaction demarcation, and all its methods must be marked NotSupported. NotSupported will result in the method being called outside of any transaction context, whether or not one exists. Enterprise beans that implement interface SessionSynchronization must have either the Required, RequiresNew, or Mandatory transaction attribute.
Q. How can I handle transaction isolation?

Answer: The EJB specification indicates that the API for controlling transaction isolation level is specific to the resource manager implementation, and therefore the architecture does not define and isolation level control API.
If a container uses only one bean instance per primary key, the container will synchronize access to the bean and therefore transaction isolation is unnecessary. Containers that use multiple instances per primary key depend on the underlying database for isolation.
Enterprise beans using container-managed persistence use the default isolation level of the underlying database; therefore, the isolation level cannot modified. Entity beans using bean-managed persistence may use the underlying DBMS API to change the isolation level (using, for example, Connection.setTransactionIsolation().)
Q. Does the J2EE platform support distributed transactions?

Answer: Yes, the J2EE platform allows multiple databases to participate in a transaction. These databases may be spread across multiple machines, using multiple EJB technology-enabled servers from multiple vendors.
Q. What are some tips for using bean-managed transaction demarcation?

Answer: • Session beans should use bean-managed transaction demarcation, although can use container-managed demarcation. Entity beans must use container-managed demarcation.

• An enterprise bean should not invoke resource manager-specific transition demarcation API methods (like java.sql.Connection.commit(), java.sql.Connection.rollback(), etc.) while within a transaction. • Stateless session beans should always either commit or rollback a transaction before the business method returns. Stateful session beans do not have this requirement. Instead of calling EJBContext.getRollBackOnly(), and javax.ejb.EJBContext.setRollbackOnly(), use the corresponding JTA API calls.
Q. Can an entity bean use bean-managed transaction demarcation?

Answer: No. Entity beans always use container-managed transaction demarcation. Session beans can use either container-managed or bean-managed transaction demarcation, but not at the same time.
Q. Should I put a transactional attribute on an asynchronous action such as sending an email?

Answer: No. Simply putting a transactional attribute on a method won't help if the resource manager can't use a transactional context.

Q. Can I use multiple connections to the same resource manager from within a bean instance that executes in an XA or a global transaction ?
Answer: A bean instance that executes in an XA or a global transaction should not use multiple connections to the same resource manager.
Specifically, a bean instance that executes in an XA transaction should not cache more than one connection to the same resource manager. Further, it should not create more than one connection to the same resource manager from within a bean method under a single XA transaction.
This is needed because even though XA allows multiple connections to be enlisted in a single transaction branch, there are some restrictions. Some resource managers do not allow more than one connection to be simultaneously enlisted in the same transaction branch.
Note however that within a single XA transaction, there can be more than one connection to a single resource manager, spread across different bean instances.
Q. Does the J2EE platform support nested transactions?

Answer: No, the J2EE platform supports only flat transactions.
Q. What is scalability and portability in J2EE?

Answer: In a software system when number of users increases tremendously then the design of software system should be as such enable it to sustain this overflow of users. This issue of growing number of users is termed as scalability. In J2EE, scalability issue is well attended with clustering of web app servers and database servers.
Java is a platform independent language, which has characteristic of ‘execute once and run anywhere’. A Java code can run in a crossed platform environment as it’s executed in its own JVM. Hence a Java code can be ported in any Operating System environment and this issue is termed as portability. An EJB can also required to be ported from one vendor EJB container to another vendor’s EJB container.

Q. What is Connection Pooling? Is it advantageous?

Answer: An EJB container provides the service of connection pooling in order to provide efficient way of database connectivity to its concurrent and continuous user requests. Whenever a client request for a database connection then an instance is picked from the connection pool to get an access to database as soon as user is through with his work instance is returned to connection pool. There is a limit specified by App server administrator for the availability of number of connections and beyond a specified limit a predefined number increases numbers of connection pool instances. When demand goes back to normal then access amount of connection pool instances are removed.
This mechanism of connection pooling helps in smart and efficient use of system resources and improving the overall performance of the whole system.
Q. How is entity bean created using container managed entity bean?

Answer: A client first locates an EJB over network through JNDI and then gets a home interface reference on the EJB. On home interface the moment create () method is called; EJB container invokes underlying ejbCreate () method with similar method parameters, creating a persistent data in the underlying database.
Q. In Entity Bean will the create method in EJB Home and ejbCreate () in Entity bean have the same parameters?

Answer: Yes, exactly the same.
Q. What are the additional features of EJB 2.1 over EJB 2.0

Answer: Compared to the 2.0 specifications, EJB 2.1 have focused the attention in trying to be more "web-services" oriented, and with the improving of some important features where the community have found some design or implementation issue, like the Query Language, the addition of a Timer service, and other improvement like Message-Driven Beans.
Everybody has noticed that the biggest addition in EJB 2.1 is the new support for the Web-Services technology. With this new specifications, in fact, developers can expose their Stateless Session and Message-Driven EJBs as Web Services based on SOAP. This will mean that any client that complies with SOAP 1.1 will be able to access to the exposed EJBs. The APIs that will allow this and that have been added, are JAXM and JAX-RPC.
The first one, JAX-RPC, stands for Java API for XML-RPC, and it can be considered as Java RMI, but unsing SOAP as the protocol.The second one, JAXM, stands for Java API for XML Messaging, and it is a SOAP messaging API similar to JMS (Java Message Service). JAXM is an API for sending and receiving messages via Web services, conceptually similar to JMS that is an API for sending and receiving messages via message-oriented middleware.
Another addition is the Times Service, that can be seen as a scheduling built right inside the EJB Container.With EJB 2.1, any Stateless Session or Entity Bean can register itself with the Timer Service, requesting a notification or when a given timeframe has elapsed, or at a specific point in time.From a developer point of view, the Timer Service uses a very simple programming model based on the implementation of the TimedObject interface.
From the enhancement side, the Query Language is definitely the topic where the improvements are definitely more visible.The ORDER BY clause has finally been added. This will improve performance on orederd queries, because this will be handled by the underneath database, and not through the code by sorting the resulting collection.The WHERE clause has been improved with the addition of MOD, while the SELECT clause has been improved by adding aggregate functions, like COUNT, SUM, AVG, MIN and MAX.
Other enhancements can be noticed on the Message-Driven Beans or the Destination Linking.
Q. What's difference between Servlet/JSP session and EJB session?

Answer: From a logical point of view, a Servlet/JSP session is similar to an EJB session. Using a session, in fact, a client can connect to a server and maintain his state.But, is important to understand, that the session is maintained in different ways and, in theory, for different scopes.
A session in a Servlet, is maintained by the Servlet Container through the HttpSession object, that is acquired through the request object. You cannot really instantiate a new HttpSession object, and it doesn't contains any business logic, but is more of a place where to store objects.
A session in EJB is maintained using the SessionBeans. You design beans that can contain business logic, and that can be used by the clients. You have two different session beans: Stateful and Stateless. The first one is somehow connected with a single client. It maintains the state for that client, can be used only by that client and when the client "dies" then the session bean is "lost".
A Stateless Session Bean doesn't maintain any state and there is no guarantee that the same client will use the same stateless bean, even for two calls one after the other. The lifecycle of a Stateless Session EJB is slightly different from the one of a Stateful Session EJB. Is EJB Container's responsability to take care of knowing exactly how to track each session and redirect the request from a client to the correct instance of a Session Bean. The way this is done is vendor dependant, and is part of the contract.
Q. Why we use home interface in EJB. In RMI we dont have any concept like home interface. why we particularly go for Home Interface ?

Answer: RMI is a lower level technology that allows java objects to be distributed across multiple JVMs. Essentially, RMI abstracts sockets and inter-JVM communications.EJB, on the other hand, is a technology built atop of RMI but does so much more than allow java objects to be distributed. It is a framework that allows you to build enterprise applications by (among other things) abstracting transactions, database access and concurent processing.
Having said this, the answer to your question is the following. The home interface is EJB's way of creating an object. Home interfaces act as factories to create session beans and entity beans. These factories are provided by the application container and take care of many low level details. Since RMI is a lower level technology, it does not offer the home interface. You would have to create it yourself.

Q. How is JDO(Java Data Object) different from VO(Value Object) ?

Answer: JDO is a persistence technology that competes against entity beans in enterprise application development. It allows you to create POJOs (plain old java objects) and persist them to the database - letting JDO take care of the storage.Value objects, on the other hand, represent an abstract design pattern used in conjuction with entity beans, jdbc, and possibly even JDO to overcome commonly found isolation and transactional problems in enterprise apps. Value objects alone do not allow you to persist objects - they are simple data holders used to transfer data from the database to the client and back to the database.
Side note: I know that many books out there still refer to these data holders as value objects but the correct term is DTO: data transfer objects. Value objects refer to objects that hold a value. A good example of this java.lang.Integer object which holds an int.
Q. What are the differences of Container Managed Persistence 1.1 and 2.0?Answer: The main difference is that in EJB 2.0, the persistence manager is responsible for mapping the entity bean to the database based on the newly introduced abstract persistence schema. In other words, you can say that the persistence manager handles persistence of your CMP entity beans at runtime.Plus, thanks to the EJB Query Language, the persistence manager is also responsible for implementing and executing find methods based on it.In the previous CMP EJB 1.1, is the developer that must declare the bean class' persistent fields as either Java primitive or serializable types, providing getters and setters for all of them.
In CMP EJB 2.0, its persistent fields are not defined directly in the bean class, thanks to the new abstract persistent schema.This schema has been developed to allow the bean provider to declare the persistent fields (and bean relationships, eventually) indirectly.
Q. Are there any tools for porting EJB Applications from one Application Server to another?

Answer: Theoretically there is no need of any tool for deployment. The porting of application from one app server to another app server can be done easily as all app servers provided by different vendors follow the same standard and specification. This is based on the fact that you did not use any vendor specific classes while building your EJB application.
Q. The Singleton pattern is not permitted by the J2EE spec, so how can I cache EJB home interfaces across EJBs in my application and avoid having each EJB get its own home interfaces?

Answer: It's true that theoretically, static objects (hence, singleton patterns) are not permitted. This is because you never know how many class loaders there are in your ejb container - unless you know the inner working of your container. Therefore, the singleton object will be unique in the class loader only. If there are multiple class loaders, your singleton object will exist more than once (1 instance per class loader). However, if you are ready to accept the fact that your ejb stub may be cached multiple times (as much as once in every class loader), the singleton pattern will still work.If ejb container's responsibility to cache ejb stubs. However, some implementation of jndi are very slow to lookup. Repeatedly performing jndi lookups can actually slow down your app considerably. In fact, I have written that exact singleton class you are contemplating and this has increased performance.
Q. What is the default time for transaction manager? And how to set maximum time(timeout) for transaction?

Answer: The default time depends on your app server. It is usually around 30 seconds. If you are using bean-managed transactions, you can set it like this:
// One of the methods from the SessionBean interfacepublic void setSessionContext(SessionContext context) throws EJBException{sessionContext = context;}
// Then, when starting a new transactionUserTransaction userTransaction = sessionContext.getUserTransaction();userTransaction.setTransactionTimeout(60);userTransaction.begin();// do stuffuserTransaction.commit();
If you are using container-managed transactions, this value is set in a app server specific way. Check your app server's deployment descriptor DTD.

Q. What is the difference between ejbCreate() and ejbPostCreate() in EntityBean? Answer: An ejbCreate () method is called just before persisting the data into underlying database in case of Entity beans. It will create a new record in the database. A create () method defined in Home interface will correspond to an ejbCreate() method in bean class with the same arguments.
ejbPostCreate() is called by EjbContainer immediately after ejbCreate() method. This method is may also be used reset transaction related parameters.
Q. Why EJB 1.1 specs says that Session Beans can have BM or CM transaction, but not both in same bean?

Answer: CMTs and BMTs are 2 different animals. Mixing them in the same bean would require the application container to potentially start a transaction at the beginning of the method while the BMT bean itself would start another. Things could get quickly get out of hand.Even mixing CMT beans and BMT beans in the same process flow can be tricky. For example, a BMT bean cannot participate in transactions started by a CMT bean (although the opposite is allowed).The real is question is why would you need to do this? Most of the time, you will use CMTs. BMTs are used in special circumstances where you need fine-grained transaction control.