see comments below "Pravin S. Tiwari." wrote: > Application Logic : The first activity is login where the client gives his > UserID and Password. This request is validated and for a valid request the > other details ( i.e. customer no , account types and account no) were > fetched in the background. Now after this a new page is sent back to the > user with a menu with different options available to him. Selection of any > option (i.e. Balance checking, Amount Transfers) will generate a new > request by invoking a new servlet and this request will refer the same data > fetched earlier, through login process (i.e. customer no , account types > and account no) and process the request. It is required to maintain the > user specific data through out the session till the user terminates the > session. > > Technical Approach : we are calling a specific servlet for a specific > client request with the required parameters and the servlet, which also > acts as a client for a session bean, will create a stateful session bean. > The parameter passed (i.e. UserId and Password) to this bean through the > servlet client will be used to get the detailed data from main database > where the necessary information is stored. We want all this information to > be alive till the user terminates the session. > > We are considering two possible approaches for session / User Data > management on the EJB layer: > 1. one stateful bean will maintain all the data throughout session. > In this approach we are having one centralized session bean which > holds the user/ session data and forwards the request to different Entity > beans after proper validations and with required request parameters. The > actual business operation will be done through the Entity Beans, which also > takes care of database specific jobs also. > Here, we need to maintain all the data alive in the stateful bean. > Every new request (i.e. every new servlet invoked form same client within > same session) needs to refer to specific instance of the bean (created > earlier with login process) for the additional data, which needs to be > added to the request and does the required process by invoking different > Entity beans where we are putting actual business code. > Kindly let me know if this approach is possible? This is an excellent approach. > If yes, then > a) Is it possible to keep the state of a stateful bean even if it's client > is not alive? Yes. > If yes, > Then how do this and also how the instance of this stateful bean will be > made available to different requests ( new servlets)? There are a number of ways that servlets can maintain session state. The two most common ones are cookies and URL rewriting. You could, for example, serialize the handle to the stateful session bean, base 64 encode it, and store it in a cookie. There are other/better ways, and your web/servlet server may provide assistance in this area. Most servers (that you pay for) do. > > b) Can we use the Entity Beans for the purpose said above? Absolutely. > If yes, then is > there any limitation on the instances, which can be created for Entity > beans within a container? No. > how to design this so that the container can > hold the data/ entity beans instances for very large number of internet > users accessing the site ? Ahhh, now that is a deep question. The only way I know to answer this is by collecting a lot more information from you, which I don't have time to do (for free). This will depend on how many concurrent users we are expecting, what web/servlet server we are using, how the web servers are deployed and configured, what EJB server we are using, how the app servers are configured and deployed, what database we are using, how the database is deployed, and several other important questions. Don't forget that stateful session beans and entity beans do not have to consume volatile memory all the time. There are mechanisms for storing them in persistent storage and reactivating them when requests come in. > > > 2. On a valid request we will create an entity bean, which will hold all > the data, fetched from the database for a specific user. > In this approach we have different Stateful beans with corresponding > servlet clients. Here the first process of login will invoke a stateful > bean specifically for login activity through a login servlet client. This > stateful bean will fetch the details from the main database. On a valid > request it will create an Entity bean containing all the user specific > data. We need to maintain userID or UserID& Password at the servlet level, > which will be passed with any request through servlet to new stateful > session bean, which will handle the client and bean state only. The user id > and password supplied with the request will be used as the primary key for > finding the Entity bean already created after login process. > Here the entity beans will be used for referencing user details only. The > interaction with the Main database is handled by different Session EJBs > depending upon their business logic. This would probably work, but is less desirable from an application architecture perspective. If you do this, the session beans can probably be stateless. > > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help".
begin:vcard n:Wilson;Chip tel;fax:(214) 358-0353 tel;work:(214) 642-4559 x-mozilla-html:TRUE url:http://www.axyssolutions.com/ org:Axys Solutions adr:;;;Dallas;TX;; version:2.1 email;internet:[EMAIL PROTECTED] title:Application Architect note:Sun Certified Java Architect x-mozilla-cpt:;-25088 fn:Chip Wilson end:vcard
