Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Session Bean with DAO  RSS feed

 
Nijeesh Balan
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
We are planning to use Session Beans
in our project. This leaves us with two options..
1. Write the sql queries inside the Session Bean.

Disadv:
If ur sql query changes by any chance..then u may have to re-deploy the bean.
2. Have a DAO which will have the sql queries and create & call it from the method of the session bean
Adv:
If the sql query changes just compile the DAO class.
Disadv(not sure):
The DAO object will be created whenever u call a method on the session bean which will mitigate the real use of EJB (i.e) eventhough the session beans are pooled, since the no., of DAO's are created for each call, the DAO number will go on increasing as the number of calls. This is what my assumption goes.
Is there anyway to avoid this or is there any method of implementation?
Please clarify.
TIA,
Nijeesh.
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Make your DAO's threadsafe singletons and you won't have the number increase. That's normally what I do when I create them anyway.
Kyle
 
Nijeesh Balan
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the immediate response Kyle.
I was just going through your article "Choosing the Right EJB Type: Some Design Criteria". it was enlightening..
can u throw some more light on "threadsafe" singletons..
and also is it better to create the "Java serializable objects" inside the DAO itself(which leaves SB with no much work other than forwarding the object to the servlet) or return the resultset to the session bean which will create the object.

TIA,
Nijeesh.
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Making a class threadsafe is as simple as not having any instance variables. If you only pass things in as parameters and use temporary variables, then your class will be threadsafe by default.
Personally, I ALWAYS leave my session beans as pure facades (e.g. "without much to do"). The rest of the code ends up more reusable that way.
Kyle
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!