ejb

[bujjimadhu]

hi friends

this is sirisha i have one doubt in ejb


what is the difference b/w stateless session bean and stateful session bean?

stateful maintain client statuc

stateless:does not maintain client status

Originally Posted by bujjimadhu

hi friends

this is sirisha i have one doubt in ejb


what is the difference b/w stateless session bean and stateful session bean?

[kiran2710]

Clustering Stateless Session Beans
Application servers can scale if they're configured such that home stubs and remote stubs balance the load of method invocations across servers. Each method call handled by a stub would execute a ServerChooser algorithm in the stub to select which server is best suited for handling this method invocation. The ServerChooser would return the IP address or connection to the server that best meets the criteria needed for this method invocation. Then the stub forwards the invocation to that server.
Since all stateless session EJBs are identical, the home and remote stubs can select, with some flexibility, the server to handle particular requests. Popular types of balancing algorithms in use today include the five following.
· Random -- A seed-based, random selection of a server to handle a request; may incorporate statistical irregularities over the short term.
· Round Robin -- Sends requests to different servers in a statistically regular way.
· Weighted Round Robin -- A derivative of round robin, it favors certain servers using ratios. Administrators and developers apply relative weights to different servers that determine how much of the load they should handle. One design pattern is to set the weight of a server that needs some maintenance to zero, thus eliminating any EJB traffic to that server.
· High Availability - A derivative of the round-robin algorithm, it "pins" a stub to a single server until the server can no longer handle the request, at which time the stub makes a "high availability" switch to the next server (which is typically done in a round-robin fashion).
· Programmatic - In some application servers you can write your own stub-based balancing algorithm as a Java class compiled into the stub implementation. The class that you implement typically has a single method that is executed whenever a remote or home stub has to select a server. The method that you implement will typically have access to reflection method and input arguments that relate to the method that the client invoked. From this information, the method generates a list of servers or IP addresses of servers to try when the stub needs to load balance. The order of this list dictates the order of the balancing scheme applied by the stub. This is a great way to implement a staging, test, and production environment for your EJBs. Depending upon the values of the input parameters or the current value of a flag specified in a text file, your programmatic filter can alter requests to different servers depending upon whether you are testing an application or running it in production mode.
Fault Tolerance

Load balancing sounds easy to incorporate, doesn't it? Well, for the most part, it is. However, incorporating fault tolerance and fail over into your EJB applications is more complicated. There are many issues involved in accomplishing a successful fail over (and to supporing fault tolerance).
1. How does a home or remote stub determine whether a failure situation has occurred? If an exception is generated, how does a stub know that the exception is a failure condition that cannot be recovered? There are three types of exceptions that a stub can receive: application exceptions (those defined by the bean developer), system exceptions (typically in the form of EJBException), and network/communication exceptions. Application and system exceptions are clearly defined in the EJB specification and are typically propagated to the invoking client to be handled. Network/communication exceptions, such as SocketException, CommunicationException, and others, indicate a much more dire, unable-to-communicate-with-server scenario. An application server stub can intercept all system and communication exceptions and may perform a fail over to another server, if it's safe to do so. Why wouldn't it be safe?
2. At what point in the invocation did the failure occur? There are three situations to consider.
a. The failure occurred before the server-side invocation started. If the stub can determine that a failure occurred after the method request was sent but before it was invoked on the server, the stub can treat this failure as a load balance scenario and re-direct the method invocation to any other available server.
b. The failure occurred after the server-side invocation completed, but before the response message was properly propagated to the client. This situation doesn't require any further action from the stub.
c. The failure occurred during the server-side invocation. The method that was invoked on the server may or may not have altered some server-side resources that impact future behavior of the system. If the stub makes a subsequent request on a method that impacts server-side resources or data, the stub may inadvertently perform the same altering action twice in a row during a failure recovery, thus causing the system to behave indeterminately. If the method doesn't perform any of these altering actions, then it could safely invoke the method again. But if it does alter the system, it cannot.
Unfortunately, even though the (a) and (b) scenarios have a very happy ending, it is difficult to determine for certain which state the system is in. As a result, a stub will likely have to assume that if a failure situation occurs, the server was in (c), the worst-case scenario, even if in fact it was in (a) or (b).
So should the application server do? Many application servers support idempotent methods, which yield the same results on subsequent invocations if the same input arguments are provided. A non-idempotent method alters the state of the system (that is, yields different results) on subsequent executions. Types of methods that are idempotent include

• any method that acts as a "reader / getter" method,
• any method that performs a non-altering query, and
• any method that accesses a resource manager, but leaves the state of the resource manager unaltered.

As a bean developer you are aware of the behavior of the methods you. Using the utilities provided by the vendor, you specify the idempotent and non-idempotent bean methods. At runtime, an application server that encounters a failure situation during a method invocation can freely perform a fail over switch if the method that was being executed is idempotent. After all, if the method doesn't alter the state of the system, then the stub may assume the existing system is intact and that a new invocation will not have odd side effects. In situations where a failure occurs on a method that is not idempotent, the stub will be forced to throw the communication exception it receives to the client. Your client application will have to determine whether it should try another invocation or not.
try {
MyHome home = (MyHome) ctx.lookup("MyEJB");

// This should use PortableRemoteObject.narrow().
My remote = (My) home.create();

remote.invokeIdempotentMethod();
} catch (javax.naming.CommunicationException exception) {

// This is a type of Naming Exception
// This is an acceptable exception for me. Calling this method again
// will not adversely impact the system.

try {
remote.invokeIdempotentMethod();
} catch (java.io.IOException exception) {

// This must be some sort of socket exception.
// I don't want to call this method again, so now it must be
// handled in another way that you determine!

}
}
Conclusion

As you can see, a variety of options exist for smoothly integrate stateless session EJBs in clustered implementations. Obviously I have not addressed stateful session beans. Statefulness adds another level of complexity since stateful bean stubs are "pinned" to the object that they represent. This reduces load balance and fail over flexibility, but they may still be done. How they are done is the topic of the next article in this clustering series. Until then, good luck and happy scaling!
The intent of Stateful Session EJBs

An Stateful Session EJB is a server-side object designed to hold data on behalf of a particular client. SFSBs should be used to store session-oriented data. Session-oriented data is used to track a multi-request sequence, ordering, or any associated data that is part of a sequence. SFSBs, however, have a limited lifespan and are not intended to survive server crashes. SFSBs are the only type of EJB that can receive callback notifications about the lifecycle of transactions that the bean participates in.


Stateful Session EJBs: Beasts of Burden

When SFSBs should not be used

· SFSBs are not server-side data caches. Yes, they do hold data in the server on behalf of the client, but that does not make them an in-memory, persistent store data cache. Yes, SFSBs are allowed to access a database and load data into memory, but the act of cacheing persistent data lies within the responsibilities of entity beans. A primary requirement for a data cache is that multiple clients should be able to access the same data concurrently based upon locking rules dictated by the developer. SFSBs are not designed to be shared resources to intuitively allow for this type of concurrent access. In the EJB 1.1 specification, concurrent client access of SFSBs was strictly prohibited. In EJB 2.0, a container vendor's implementation may permit concurrent client access of a single SFSB. Despite this new capability in EJB 2.0, SFSBs should not be used in a design that calls for multiple client concurrent access because they make it easy for a developer to code a deadlock.
The only data that should be cached within an SFSB is data pertaining to tracking the sequence that the SFSB is managing. I've seen too many clients take 30 minutes to build an SFSB with persistent data and then spend 30 days trying to architect a solution that converts the bean into a transaction-aware data cache. Just don't do it -- you are setting yourself up for guaranteed failure.
· Part of this misperception about SFSBs comes from the wording within the EJB specification itself! The EJB specification suggests that a shopping cart for an e-commerce system could be implemented with SFSBs. This is perfectly acceptable if that shopping cart is only intended to be an in-memory implementation that does not need to survive a server crash. In reality, however, most implementations of shopping carts are required to survive server crashes; the data contained within the shopping cart needs to be persistent and transactional -- with an in-memory data cache.
Developers may be confused because if you read the EJB specification incorrectly it could be interpreted as saying all shopping cart implementations can be implemented with SFSBs. That simply isn't true. All in-memory shopping cart implementations can be implemented with SFSBs, but if you need to implement a persistent, crash-friendly shopping cart, you need to use entity EJBs.
· SFSBs are not distributed data stores. Yes, many application servers provide SFSB replication of state to allow for failover of requests to provide a higher level of availability. SFSB replication is just that: a replication mechanism to resist failures of instances on a single machine. SFSB replication is not designed to resist cluster-wide failures nor is it designed to cache data across an entire cluster. If a cluster has SFSB replication and all of the servers hosting a particular SFSB crash, that SFSB is permanently lost. This will happen, even if there are other servers that are still active. This is perfectly acceptable and should be accounted for when using SFSBs. If an SFSB is only used as a session-oriented component, the worst-case scenario that occurs is that the sequence is restarted from scratch when all copies of a particular SFSB are destroyed.
When SFSBs should be used in non-web systems

For systems that do not have a servlet/JSP front-end, SFSBs should be used to track session-oriented state similar to the way a web-based system would use an HttpSession object. This was the primary intent of SFSBs when they were created.
When SFSBs should be used in web systems

Systems that have JSP/servlet front-ends should use HttpSession objects to store session-oriented state on behalf of a client. Applications that manage an HttpSession object and an SFSB for a single client wind up duplicating effort that does not need to be duplicated. There are two reasons to use an SFSB in conjunction with an HttpSession object:
· Your application server does not provide cache management of HttpSession instances and your system is expected to have a large number of concurrent clients. Containers for SFSBs can activate and "passivate" the state of instances to and from a secondary store. This allows a container to create an upper limit to the number of instances that will exist in memory at any given point in time. The number of concurrent clients can exceed the limit of SFSB instances in memory because the container can swap idle instances to and from the secondary store. The container will never allow more than the limit of SFSB instances to exist in memory, subsequently placing all additional instances into the secondary store. This provides a greater level of scalability to the system through effective memory management.
Many application servers provide similar cache management of HttpSession objects. Because HttpSession objects are similar to SFSBs, they can also be made passive and active. Cache management behavior of HttpSession objects is not required as part of J2EE and is considered a vendor value-add. If your application server does not support HttpSession cache management -- and you need to control the total number of session-oriented instances in memory at any given time -- you should place the bulk of your session-oriented data in an SFSB instead of an HttpSession object. You will still need to maintain an HttpSession for each client, but the only item in the HttpSession should be a reference to the SFSB for that client. If the only item in the HttpSession object is a reference to the SFSB, the amount of memory consumed by each HttpSession object is minimal and cache management of these instances is not needed. The bulk of memory consumption will occur within the SFSBs, which have a standardized strategy for allowing a container to perform cache management.
· Your session-oriented objects need to receive notifications on the lifecycle of the transactions they participate in. SFSBs can implement the SessionSynchronization interface. The SessionSynchronization interface contains three methods that a container invokes as a transaction migrates through the lifecycle the SFSB is participating in. An SFSB might implement the SessionSynchronization interface as a way to return the data of the SFSB to its original state whenever there is a transaction rollback. HttpSession instances do not have a mechanism that allows them to receive transaction notifications. This means that any data that is modified in an HttpSession during a transaction will not be reverted if the current transaction is rolled back. All changes to data in an HttpSession object are always durable despite the outcome of any executing transactions. If this behavior is not appropriate for your system, placing all data into an SFSB instance that implements SessionSynchronization will give you the appropriate behavior.
Conclusion

SFSBs have their place in J2EE systems; it's just very small. If your designs use SFSBs for session-oriented data and avoid using SFSBs as distributed data caches, your systems will be more reliable. If you have a requirement you think SFSBs can satisfy and that requirement is not listed in this article, you should give some hard thought to another solution.

[sravanse]

stateful sessbean can maintain d client state(i.e., dat or info) across method calls. but, in case of
stateless, it cannot. that is why stateless bean's home interface is having only one create() method, that too without any arguments.

So, the instances of stateless beans can be pooled n maintained for multiple users. whereas, stful beans are specific to a client n it contains dat client cl specific info so,, can't be pooled.

Remember, stateless beans donot contain client specific state, but can contain global info.