• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Do we need session beans with out entity bean's presence

 
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am doing desing for a web based reporting application. I use JSP for view , servlets for controller and then DAO's for talking to database. Value Objects carry information back and forth. I user application server's Data Source for getting connections via thin driver.
Number of records in each table that I talk to are in lakhs.
If I introduce Session beans between servlets and DAO , how will I get benefited ?
Will it increase performance in any way ?
Do we need session bean if there are no entity beans in the application
Please clarify.
 
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Of course you can use Session Beans without using entity beans. Though, I haven't understand one thing. Where is the business logic implemented? Inside the servlets?
If so, you should add an extra layer (between the servlets and the DAOs) which should implement the business logic. You can use Session Beans and thus you will benefit from CMT (Container Managed Transaction). You could use POJOs but if you choose this solution you will have to implement the transactions by hand.
Of course, performance will not be better unless it's an applications with a lot of simultaneous connections. If performance is an issue than you should use simple objects for the business logic, but you will not benefit from all the features Session Beans offer.
 
Ranch Hand
Posts: 977
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
another thing u should consider is that if u decide go for session beans it's going to be easy to add no web clients in the future to access u'r business logic, from remote clients, cell phones, etc.
Another thing is that it'll be very easy in the future to expose u'r services as web services.
regards.
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If You are using session bean, then objects will be created by the application server before hand and will be served to you as on when required. The object creation is quite expensive operation.
Regards
Susil Parida
HCL Tech
 
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Susil Parida:
[QB]If You are using session bean, then objects will be created by the application server before hand and will be served to you as on when required. The object creation is quite expensive operation.]


This is only a real issue if you use stateful session beans. Stateless beans are pooled by the container and are quite efficient, especially if you use them locally. If your application requires transaction support and/or security functionality in the business tier then session beans are the way to go. However if your business services are relatively simple and you can get away with security in the web tier and handling transactions yourself you at least need to have a business delegate between your DAO / Servlet. EJB may be overkill unless you really need its services.
 
Susil Parida
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I fully agree with Louis's statement. It is the architectural decision to go for what depending on the volume traffic it intended to handle, the kind of infrastructure they are going to provide. If somebody is going to hanle 100 users a day then it is better he should go for no EJB, if the volume is high and having high capacity servers at disposal then should go EJB (Statefull and Stateless as per the application requirement).
 
Manas Ahlaad
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Someboday has said, if you use EJB's ,objects will be pooled by container and given to you as and when you need them. But what's the point ,I still use DAO's , Servlet's. container will pool only EJB objects. How will that improve/effect my performance ??
For my application , Business logic is written in Database Views. So do I still need one more layer between DAO and Servlets??
Please let me know your comments.
 
Watchya got in that poodle gun? Anything for me? Or this tiny ad?
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic