Replies inline below. ----- Original Message ----- From: "Prashant Sarode" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 09, 2001 12:28 AM Subject: [JBoss-user] Some Questions abt Session & Entity Beans
> Hi all, > Can u pls tell me the answers to the following questions: > > 1. If 1000 users are accessing StateLess Session Bean, how many instances > of it are created on the server (say Weblogic v6.1) ? A lot less than 1000. Beyond that it depends on configuration of pooling on the stateless bean, and how many simultaneous invocations are made. > > 2. When should we use Entity Beans ? If I have to update only 1 field of 1 > table, should I use Entity Beans or not ????? Also, if there are 2/3 > tables > to be inserted or updated, should I go for 2/3 Entity Beans or should I > go for only StateLess Session Bean without using Entity Beans ????? Some of this depends on the capabilities of your container. In your first example, for instance, some containers will generate optimized SQL that only updates the field that actually changed - others will blindly update all columns. Entity beans can give you some advantages, particularly with CMP: 1. Faster development - CMP lets you not write (as much) SQL and data manipulation code. In a green-fields app a good CMP container (JBoss is really strong here) can really let you get stuff done quickly. 2. Entity beans give you an OO api in terms of your domain. This is important in terms of maintenability and reuseability. You can also use more traditional OO techniques to accomplish this, of course, but entities give you this in combination with the other advantages. 3. Entity beans are transactional, persistent 'components'. This helps you build ACID transactions more easily 4. Entity beans provide a simple, declarative security model at a fine granularity. You can specify which sorts of users can see what fields, even. 5. Some containers provide sophisticated cache management that can help your application cut latency while still scaling, in some cases. 6. To standardize on an approach accross an enterprise Entity beans also have some disadvantages: 1. Containers often implement only fairly simple OR mapping capabilities - one table per bean, for example. This can negate advantage 2 by forcing you to have artificial implementation constructs, or advantage 1 by making you write more SQL to implement complex relationships. 2. If your container can't manage the object relational mapping you need, your stuck writing SQL by hand anyway. 3. The raw EJB security model is often lacking in some details (no way to do state-based security rules [role B can only approve loans under 500$, for example]) and this fine grained declaritive security needs support from your presentation (UI) to provide a decent user experience. 4. Raw latency responding to a request is higher because of the additional layers. This can be managed through carefull use of certain patterns (session wraps entity, group accessor, etc.). This is the price paid for scalability, transactionality, and security. All in all, you really need to weigh the advantages and disadvantages in each particular case. > > 3. If there r multiple screens, say registration process involving 5 to 6 > screens, what should we use? > > a. Stateful Session Bean or > b. Simple HttpSession Object keeping the data in the session till 6th > screen > & then in the last screen, insert it into the database. or > c. Simple HttpSession Object keeping the data in the session & inserting > it > in the subsequent screens into the database. > d. Using a Stateless Session Bean Generally, you'll want to use one of the first two. You probably don't want to jam session data into the database on every request in this case (unless that's how you're supporting clustering/session fail-over in a non-clusterable app server). If you use a stateless bean, you'll need to do one of the other three anyway, unless I'm missing your point. Historically, I've urged people to do b, because statefull beans impose quite a bit of overhead on the container. I've recently seen some rules of thumb from another vendor pointing to using statefull beans when the size of the session data gets over 400K or so. Again, it depends on your needs and environment. > > 4. Finally, if I can do all the programming using JSP, Servlets & simple > beans, then why should I go for EJBs ? You might not want to, if your application is of low to medium complexity, and you don't see reusing much of the back end logic in a different context. However, once you get to the point where you need an ACID transaction spanning multiple logical entities (entity in terms of ERD modelling here, not neccessarily Entity EJB), the transaction and resource management that the container provides can save you a lot of headaches while allowing you to write modular, reusable OO code (if you design it right!) Even in the simpler case, a good, developer-friendly EJB container (JBoss, for example) can let you knock out an app quickly while letting you not worry about a lot of things. Besides, it's pretty cool, all the stuff that it does under the covers 8^}) > > I've seen plenty of sites of EJBs but still couldn't get the proper > answers to the above questions. Hoping to get it from u guys. I hope this has helped. -danch _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
