Rahul Devgan

Greenhorn
+ Follow
since Aug 04, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Rahul Devgan

Hi All,
I was hoping for some answers, guidance whatever my intelligent fellow beings can throw at me!
Hi,
I would like to understand as how to incorporate frameowrks into designs? More specifially into J2EE design implementations. How do I draw my class diagrams, sequence diagrams and component diagrams when i am using frameworks like Struts, Spring etc?
Apologies if this question is out of place. In such case please redirect me to the right forum.
Well, did you try downloading the .tgz file an unzipping the same.
Hi Ganesh,
Maybe you would like to post this question in the proper forum:

https://coderanch.com/forums/f-61/po
Hi Vikas,
Well, this is not a problem but the way Session Beans work. Each method call from client is an individual call and the session bean considers them to be 2 different clients, for simplicity.
When the first method id called, a session bean object is pulled from the pool, services the request and is then sent back to pool, you can think of it on similar lines to being GC. When you call the SB next time, any SB object can be called from the pool and this will have everything given to it fresh, including your hashtable.
If, you need to populate data into a hastable in one call and use it another then you can cache the hastable on the client side and not on the bean side. There are several ways to achieve the same including using the Server's cache, if it provides one or simply creating a hastable in your client code and then passing it to second method.
Hope this clears things and is useful to you.
Whether ther ServiceImpl is fine grained or not, I can not presume and it will not be a good idea to presume that. Whatever my views on this were contextual, without considering anything other then what was stated in the original question.
On the performance side, considering the big O of complexity, it is always better to keep the number of objects floating around at runtime to a minimum. Now I am now saying that POJO is a big overhead or not but simply answering again based on the context of the question. Why even one extra object, when the same can be avoided?
Reflecting further, what he has also suggested is a separation of concerns to a finer level. The bean does not care about how the biz logic will be implemented and is only taking care of life cycle implementation, if any. This keeps the code cleaner and allows the biz logic to be handled by a not so great J2EE pro but a gr8 domain expert. Anyways, as long as the methods get called on the remote stub, it is all transparent to the client and under control of the J2EE server, which is what is desired afterall.
I have different take on this. Am just trying to reason why your architect might have suggested the approach of using the super class. I am not sure how complex your system is or how many methods this Session Bean has but I think the rationale behind his decision is performance and memory consumption. If we have a set of wrapper methods, then the EJb does not own the actual method and the JVM would create a object of the class implementing the methods. However, if the EJB is a sub-class then the implementation is within the EJB and the number of objects at runtime would be lesser.
I did not understand the remote object accession scenario mentioned by Jeremy and can not see how it is related to the question asked. If the client is remote the remote overhead would always be there whether we use wrapped or sun-class approach.
I agree with Roger. What is the need for going for either CMP or Hibernate if you are using the DAO pattern. It abstracts the accession to data from other layers using the same.
Hi,
After I posted my last reply I was able to see the replies to my original message.
Thanks Jeremy for your inputs. I am aware of the Service Locator Pattern and local and remote interfaces of EJB. However, I just wanted to clear a few confusions creeping into my mind and see what other have to say about them. Also, the SCEA is based on EJB1.1, J2EE 1.2, so am not sure if we can use local interfaces in our designs. Any clarifications on this.
On the main SCEA page, I can see 5 replies to my topic but when i click the link to this topic, I can only see my original message and none of the replies.
i was able to view the 2 replies about 2 days ago.
Hi guys,
Thanks for your replies.
Well, the essence of my question was how do we cache Entity Home Objects, without knowing whether they are remote or local, so that we can get some performance benefits. There being several ways to do it, like creating a home object in the ejbCreate of the Session Facade and having a global reference to the same or using a helper class, as mentioned by Jeremy, which gives us cahced homes. I wanted to find out the best approach for the same.
What do you guys think is the best approach?
Hi All,
Please enlighten me on this one; Is it a good idea to put a Business Delegate between a Session Bean and Entity Bean, if I do not know whether the entity is local or remote? I believe the Session Bean(a Session Facade) is a client as far as EB is concerned and there should be a BD inbetween just like between a Servlet Client and Session Facade.
One can say that try the to contact the Entity locally first and if not available then contact it in the catch block remotely but the same can be done in BD with a service locator to find the entity home.
Please respond.
Thanks again for correcting me there and for initiating me on a trail...