DAO with Stateful Session Beans

[Seid Myadiyev]

Mock Exam Question:
When would you use the DAO pattern in regards to a Stateful Session Bean?
The correct answer given in the same exam is:
You would NOT use DAO with Stateful Session Beans.
So my question is: Why not? Stateful Session Bean accesses database not for its persistence but for business methods to access data!
Also Sun BluePrints recommends that!
What do you think?
_________________
Here is original text of Designing Enterprise Applications with the J2EETM Platform, Second Edition (2002):
Page Number: 161-162
5.7.5.1 Clarifying Bean Implementations
When a session bean or an entity bean with bean-managed persistence needs to access a database within a method implementation, a corresponding method in the
data access object implements the actual logic of fetching or updating data in the database. This removes the data access logic from the enterprise bean implementation.
The bean’s business logic is not cluttered with data access calls, such as JDBC calls, making it much cleaner and readable. For example, consider the Catalog session bean. The business method getProducts needs to return all the products for a category. Whenever getProducts needs to operate on data residing in the database, it hands over control to a data access object. The data access object formulates the query, fetches the result set, and returns the data in the desired format to the bean’s calling method.
In the sample application, the implementation of the Catalog session bean is provided by CatalogEJB. The code for CatalogEJB.getProducts appears in Code Example 5.7; the code for the corresponding data access object appears in Code Example 5.8.

[Rufus BugleWeed]

I agree with you. DAO is to decouple the application from the data source.
One problem I could see would be the stateful bean holding a reference to the DAO. That's a memory leak isn't it?

[Alex Pisarev]

Originally posted by Rufus Bugleweed:
I agree with you. DAO is to decouple the application from the data source.
One problem I could see would be the stateful bean holding a reference to the DAO. That's a memory leak isn't it?

I afraid that we could need some more elaborations here.
DAO is originally a Microsoft term, I propose to stick with Floyd Marinescu's DTO definition. Although Sun uses DAO term, I think it's a bit confusing.
DTO can be used with any beans you want - as Rufus said it's just decouples your data manipulation methods from your business methods.
I can't see any objections of calling DTO from stateful bean - DTO usually doesn't hold any state (however, you could erect some cache on top of it and develop it up to a complex framework - but it would not be old-is-gold DTO anymore, wouldn't it?). The point is that it's not so easy to find a case when you would have a certain need of using DTO with your statefuls - so in most cases the use of DTO with statefuls could be considered as an architecture drawback. That's my 2 cents.
Alex

[Chris Mathews]

DTO != DAO
DTO is Data Transfer Object. This is the same concept as the Core J2EE Pattern called Value Object (since renamed Transfer Object). Floyd (no disrespect) just changed the name and modified the intention based on changes with EJB 2.0.
DAO is Data Access Object. This is the Core J2EE Pattern that abstracts access to a datasource. DAO is used with BMP to attempt to decouple the EJB implementation from the database and allow for easy migration between database vendors.
Personally I think it is valid and preferred to use DAO with Session Beans. It sure beats directly coding your JDBC in the Session Bean itself.
On another note, just because a Session or Stateful Session Bean uses a DAO does not mean that it needs to keep a reference to that object. The DAO could be made a Singleton or just created upon each use.
[ September 10, 2002: Message edited by: Chris Mathews ]

[SPAD]

Chris you are 100% correct...
i will add ...

Your message was edited since you quoted content from the actual assignment. Please read our policy on SCEA questions and refrain from discussing actual assignment issues.
Thank You!

[ August 13, 2003: Message edited by: Ajith Kallambella ]

[Sanjay Raghavan]

Hi,
When the author says that you would not use DAO with a Stateful Session Bean, the key to note is ‘Stateful.’ Again the answer is ‘would not’, not ‘cannot.’
DAO is a very powerful concept and often used with Session Beans as correctly pointed out by several people.
Since Entity Beans are normally used only when dealing with concurrent shared data, for simple operations like Catalog Retrieval e.t.c, a Stateless Session Bean with DAO is often employed.
Stateful Session Beans are only used for maintaining conversational state with clients. They are generally more expensive in terms of resources (they are not pooled) and are therefore not normally used for database operations.
Hope this clarifies the point.
Thanks.

[Seid Myadiyev]

Sanjay,
First of all thank you for the SCEA@Whiz mock exam! I learnt many important points for the actual exam and I feel better and better prepared with each day!
So in this question what exactly is being asked of me:
1. Is it good idea to use DAO with Stateful Session Beans
OR
2. Is it good idea to access data from Stateful Session Beans
Thank you for your clarification!
Seid

[Alex Pisarev]

Originally posted by Seid Myadiyev:
Sanjay,
First of all thank you for the SCEA@Whiz mock exam! I learnt many important points for the actual exam and I feel better and better prepared with each day!
So in this question what exactly is being asked of me:
1. Is it good idea to use DAO with Stateful Session Beans
OR
2. Is it good idea to access data from Stateful Session Beans
Thank you for your clarification!
Seid

I think the first one, but I'll repeat again - it fully depends on your architecture.
Alex

[James Liu]

Hi seid,
I think it is ok use DAO with stateful session bean, actually I use it in our projects for a while, it is working fine.
In my opinion, DAO is just data access object, all the other objects want to access the database, it calls DAO to do it. So no matter it is stateless/stateful/BMP Entity bean, or even servlet, it always call DAO to do it. It makes code very clean ( all the sql in one layer), if in the future I want to switch database, it is much easier to do it. Also it is good for reuse.
Just like chris said, 'DTO' is just a value object, it is good for performance when passing cross network and methods.

[Steven Wong]

Hi,
I would propose that you actually put all your data access logics in the DAO whilst your session bean only does those business logics.
Pertaining to whether you should use stateful or stateless, it really depends on what you are catering for that session bean.
For instance, if you have a caching list page, you could use the stateful session bean to cache your records whilst if it's just normal database calls with no records being cache, then use stateless session bean.
Hope it helps.

[SPAD]

I will repeat what I have learned - DAO are for putting your logic for accessing the data.
Now if you think your components have a need to access the datasource use it as its the best way.
So your question boils down to :
Whether you should access the datasource/db from your stateful bean ? Why not if there is a need ?
E.g., there might be a business logic that need topick up some values/data for calculation from DB.

[Sanjay Raghavan]

Seid,
Sorry for not responding earlier.
As Alex and others point out, there is seldom a right answer for questions. In many cases, whatever the business warrants is the best solution.
This particular question, taken by itself (without circumstantial data) should be interpreted as:
1. Should I generally use Stateful Session Beans for for any database access processing?
The bit on DAO has carefully be added to confuse the reader. DAO is a common mantra in best practices books. Hence the reader is tempted to think along the lines of database access best practices, while the main stem of the question simply wants to know whether you understand the best use of the bean type specified.
Again, without any circumstances described, the SFSB guidelines simply talk about conversational state oriented workflow, while the SLSB guidelines talk about stateless workflow. Whenever simple database operations are mentioned, again the gurus tilt in favor of SLSB.
Hence the answer.
Does this help?