61). Why did I get a LockTimedOutException?
62). What is the life cycle of MDB?
The lifetime of an MDB instance is controlled by the container. Only two states exist: Does not exist and Ready , as illustrated in the following figure:
The life of an MDB instance starts when the container invokes newInstance() on the MDB class to create a new instance. Next, the container calls setMessageDrivenContext() followed by ejbCreate() on the instance. The bean then enters the Ready state and is ready to consume messages.
When a message arrives for the bean, the container invokes the onMessage() method of one of the available instances, passing a Message object in argument. Message s can be consumed and processed concurrently by using multiple instances of the same type.
The container invokes ejbRemove() on the bean instance when it no longer needs the instance. The bean instance can perform clean up operations here.
63). Can an entity bean be a listener for JMS messages?
No. Message driven beans should be used to consume JMS messages.
64). What is Entity Bean. What are the various types of Entity Bean?
Entity bean represents the real data which is stored in the persistent storage like Database or file system. For example, There is a table in Database called Credit_card. This table contains credit_card_no,first_name, last_name, ssn as colums and there are 100 rows in the table. Here each row is represented by one instance of the entity bean and it is found by an unique key (primary key) credit_card_no.
There are two types of entity beans.
1) Container Managed Persistence(CMP)
2) Bean Managed Presistence(BMP)
65). What is IIOP ?
It is Internet Inter Object Resource Broker Protocl
66). Why don't stateful session beans have a pool?
Stateful session beans get instantiated once for each seperate client request and it stores the client information in it, there is no threading concept in EJB hence if there will be an instance pool will exist then there is a possiblity of information leak between different session objects.
therefore there is no concept of instance pooling in stateful session bean.
67). Without using entity beans can we do database transactions?
Without using entity beans we can do database transactions through Springs .Spring can be used to configure declarative transaction management, remote access to your logic using RMI or web services, mailing facilities and various options in persisting your data to a database
68). What is the use of using session facade design pattern in EJB'S?
There are many uses, important one is to reduce network traffic I you are calling many EJB from your Servlet then this is not advised, because it has to make many network trips, so what you do you call a Stateless session bean and this in turn calls other EJB, since they are in same container there is less network calls other thing you can do now is you can convert them to LOCAL EJB which has not network calls. This increases your server bandwidthJ. Problem solver this is good for a highly available system.
69). What is the difference between session and entity beans? When should I use one or the other?
An entity bean represents persistent global data from the database; a session bean represents transient user-specific data that will die when the user disconnects (ends his session). Generally, the session beans implement business methods (e.g. Bank.transferFunds) that call entity beans (e.g. Account.deposit, Account.withdraw)
70). Is it possible to share an HttpSession between a JSP and EJB? What happens when I change a value in the HttpSession from inside an EJB? –
You can pass the HttpSession as parameter to an EJB method, only if all objects in session are serializable.This has to be consider as passed-by-value, that means that it’s read-only in the EJB. If anything is altered from inside the EJB, it won’t be reflected back to the HttpSession of the Servlet Container.The pass-by-reference can be used between EJBs Remote Interfaces, as they are remote references. While it is possible to pass an HttpSession as a parameter to an EJB object, it is considered to be bad practice in terms of object-oriented design. This is because you are creating an unnecessary coupling between back-end objects (EJBs) and front-end objects (HttpSession). Create a higher-level of abstraction for your EJBs API. Rather than passing the whole, fat, HttpSession (which carries with it a bunch of http semantics), create a class that acts as a value object (or structure) that holds all the data you need to pass back and forth between front-end/back-end. Consider the case where your EJB needs to support a non HTTP-based client. This higher level of abstraction will be flexible enough to support it.