This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'm actually currently attending a course on the supbject of this very forum! I'm right at the beginning so I have a very simplistic view of things right now! Now as I understand it so far: There are three types of EJB; Stateless Session, Stateful Session, and Entity. Entity EJBs are good for stuff like Bank Accounts, Stateful Session EJBs are good for stuff like Shopping Carts, what is the equivient relevent example for Stateless Session EJBs?
Pounding at a thick stone wall won't move it, sometimes, you need to step back to see the way around.
Stateless session beans do not maintain any conversational state (hence the name) between method invocations. Stateless EJBs can only use the data passed in its parameters. They are especially well suited for DB lookups (get me all the books that have Java in the title) or DB stores where you don't care about persistence (credit card payment with all information sent as a parameter).
Joined: Mar 02, 2000
Ok so they kind of just pass data along without doing anything to it right? please correct me if I have this wrong.
All Session Beans are there to represent some sort of business process. The difference between stateful and stateless session beans is as the name suggests: stateful retains state between invocations and stateless does not (although they could have non-conversational state internally). The data access example is a good one although a session bean could alternatively delegate the data access part of that to one or more entity beans (representations of persistent data) True, business methods can be performed in a single request, but there is no reason why they shouldn't use other components (other stateless session EJBs for example) to perform their function.
just to give an example, If we have to search the database for some specific records, like all java books, one way we can do it is to use finder method for Entity beans and get a list of entity beans from which we can read information one by one. This may work fine if you had 10 or 20 java Books, But suppose you have 20000 java books ( we may not be far away ) then it would take really long time to create 20000 Entity beans and finally destroy those objects after displaying the list to the user. So you would like to write a good old query to search the database. Session bean is just right for doing that. you can borrow Database Connections from the connection pool maintained by the Container.
I think basically you go for Stateless session beans if the client request last only for one method call. If it lasts for multiple method calls then stateful session beans can be used. But in both the cases, point to remember is these beans can cater to only one customer/client. If u want ur beans to be shared by multiple clients at the same time, then the best alternative is entity beans which are actully the represenattion of the data. (Session beans only models the business process.) So session beans does not survive server crashes whereas ur entity beans will.