Sure depends on the particular use case in question. However, I would be hard pressed to use entity beans. Especially if DB interaction is high, it may affect your performance. Besides you are gonna use this in webservice. If you are using Document centric message style, you will be doing your own XML conversion from the data returned. A Session bean with either direct JDBC call coupled with Javebean style DTO's, will porbably scale well. If database independence is not a requirement, then I might also look into the possibility of using stored procedure and calling it from Session bean. That way you can exploit DB specific features ( analytical functions, DECODE, DATE FORMATS in case of Oracle ) and return a result set back to session bean.
Joined: Mar 11, 2004
Thanks Neelesh for getting back.
Yes, there will be a 'very heavy' traffic and there fore by what you guys have suggested, I will concentrate on using entity beans.
Joined: Oct 27, 2004
Hari Priya ---------------------------------------------------------- Thanks Neelesh for getting back.
Yes, there will be a 'very heavy' traffic and there fore by what you guys have suggested, I will concentrate on using entity beans
Hi, May be I was not clear in my reply sorry. I will NOT use entity beans !
My options would be : 1. Session bean calling a stored proc that returns resultset(s) 2. Session bean with plain jdbc.
For heavy DB traffic, entity beans will kill your app. They are good when your underlying schema is highly normalized and when only your app has exclusive access to the DB. With enterprise apps, most of the times, there are more than one applications talking to your data.
If you just want to retrieve data I prefer Session Beans. You can use either stateful or stateless bean based on your requirement. Most of the web applications I worked using session beans not entity beans. You can use Session Beans with DAOs