Hi could you please help me answering this questions ? 1)Can one implement the singleton pattern as an EJB? 2)How will you partition the work between JSP, servlets, and EJB�s? 3)Please tell us why you think you are the best candidate for this position.? 4)In an n-tier application, both the web tier and the EJB tier need to maintain session state. How will you ensure that a given client session is mapped correctly to both of these state objects? 5)What are the benefits of the Session Fa�ade pattern? When will you not use it? 6)What are the steps you need to perform in order to develop a stateless EJB, a stateful EJB, and an entity EJB?
1)Can one implement the singleton pattern as an EJB? - I think it is not possible. Singleton pattern ensures that there is only one instance of a particular java class type instantiated and used by the appliation throughout. The life-cycle of EJBs is maintained by the Container.There is no way to control instantiation/destruction of the beans in the code. Some App servers provide the ability to configure the maximum number of SLSB and MDBs that can be instantiated, but again that is vendor-specifc. 2)How will you partition the work between JSP, servlets, and EJB�s? - Using an MVC archiecture for the project. JSP-View, Servlets-Controller, EJBs-Model 3)Please tell us why you think you are the best candidate for this position.? - That's a stupid question. Some people do ask this question, especially for the junior positions, just to see what kind of a stupid answer the candidate would give.You need to come out with something by urself.U can also try the Jobs Discussion forum. 4)In an n-tier application, both the web tier and the EJB tier need to maintain session state. How will you ensure that a given client session is mapped correctly to both of these state objects? - I do not know the answer. Perhaps, may be the stateful session bean's remote reference stored as part of the HttpSession Object would help. This wouldn't work in a clustered env though.
5)What are the benefits of the Session Fa�ade pattern? When will you not use it? -Session Facade pattern provides a single, simple interface to the client. - Hides the complexity of the entity bean relationships. - Centralization of the various business interactions.The Session bean implement the business workflow by accessing the other session/entity beans. - Reduces the number of remote calls, if the entity beans have only remote interface, as remote calls are expensive to the client. When will I not use use Session Facade Pattern? - I do not know the answer. Maybe if the business process is simple and the EJBs expose less number of business methods to the client.Maybe if my EJB Project has only MDBs.....I would be glad if somebody else can answer this question as I am not the expert in EJB and Patterns...
Originally posted by Pradeep Bhat: Can you tell me why? :roll:
Let's assume that the HttpSession is replicated to each server on the cluster and the load balancer does not do sticky sessions. This would mean that each (well, most likely two at a time) web container would have a handle to the same stateful session bean. Now, if two client requests come in roughly at the same time and both requests require touching the shared handle, two threads might attempt to call the stateful session bean simultaneously -- which would lead to one of the calls failing. Can anyone confirm whether this is a real issue?
Well, if your WebLogic/WebSphere/whatever is clustered, it probably means that each HttpSession instance is replicated with other servers within the cluster in order to provide failover functionality. If you store an EJB Handle into the HttpSession when a request comes to one of the servers in the cluster, that handle object also gets replicated to other servers in the cluster. Now, if the same user causes two simultaneous requests (due to using HTML frames, for example), which happen to use the EJB Handle from HttpSession, the result is two simultaneous calls to the same SFSB instance. This could lead to the EJB container throwing an exception for one of them, as only one thread is allowed to access the SFSB instance at a time. I'm not saying that this is the absolute truth, but I think it's a possibility. Besides, not using sticky sessions is (in my experience) a rather rare case...
Joined: Aug 27, 2003
Lasse is right.In the case of multiple frames being used, there are chances that multiple requests for the same SFSB object could arrive, resulting in RemoteExeptions...The user can also click on the stop button on the browser or refresh. In terms of busy hours on the site, the chances that this could happen exist. In the case of a fail-over in a clustered environment, the SFSB state replication time is dependent on the size of the conversational state, that the bean contains. There is a chance that the updated state could be lost, when the server that is currently interacting with the client goes down before the replication process is actually completed... My view is that SFSB in a clustered environment do not scale favourably, when compared to entity beans, SLSB, MDB. SFSB and HttpSession can be used together to maintain client side, but which one is suitable to hold more client specific data is debatable.
Ok w'd be great if somebody c'd verify this.. Whether we have a cluser or not , a stateful session bean can still get concurrent requests for reasons aready pointed out and that may still result in exceptions and the bean geting destroyed as a result.