Sagar Shroff wrote:Thanks for your reply , your answer makes sense.But i dint understood one statement of yours
Dirk Schumacher wrote:You would have to do that manually. Most likely you would end up doing that by using stateless EJB services.
How would your maintain session manually using stateless EJB ?
I just gave it a thought how I would do it in case I would have to implement it with the precondition of not using SFSB.
Goal is to persist the conversation state w/ a client in the backend which it loosely connected to the web request (Http, simple GenericServlet for e.g. XML stream handling, some XML JEE handling mechanism.)
This would be my general Session handling SLSB interface, which:
The pattern to follow is that calling doWhateverInTheSession
implies that that register
was called. Though the doWhateverInTheSession
could register the session itself by checking the active session. It's up to your fantasy or use case.
If I remeber right, depending on the JEE version, it is not even possible to directly use a SLSB in a Servlet. In other words the container will not inject the SLSB into the Servlet. You would have to do that manually by using a remote SLSB.
This case you could also manually inject remotely a SFSB bean. More on the key of the problem at the bottom...
On an Http-Service (Servlet, JSF, Struts-Action,... which are all somehow in some way inherit from a Servlet) I would use the HttpSession Id to identify a client by using a SLSB with the following service methods:
Of course there needs to be done some more code in the servlet handling like creating / recognizing the http servlet session.
On a simple (generic) servlet receiving an XML for example the key is to recognize the client in order to map the client to a session.
Two ways to do that, but the latter I never implemented...
1. the XML must contain the login information to know about the user, for example:
Map the /root/@user/text()
to register or get the Session. Each request must have the user set being used as the session id.
Actually there you have your session created anyways by the user and you must not use a session service. Most likely there is the need to track the conversation anyways by inspecting the xml.
2. Use Authentification which works with http: http://en.wikipedia.org/wiki/Basic_access_authentication
I do not know straight away how to access the current user within a servlet there. But this is moving the information of /root/@user/text()
to a more basic level at the http request call stack.
From here it is getting fuzzy since your use case is not known. Also it is not known what and where your information of your client (which maps to a session and could make it a stateful conversation) is located.
Inspect what information about your client is available where at each of your requests to the server. If you do not have identifying information of the client then you probably must provide it.
The goal is to map that identifying client information of the request on the server to a stateful conversion wherever this is located. The IP address is most not of use since it cannot safely determine a unique request caller.
For example an HttpServlet (which is a framework based on GenericServlet based which is framework based on java.net.ServerSocket) is somehow using Cookies, URL-rewriting, ... to archive that goal.
The nature of TCP/IP is stateless for each request. Any program having converstion over TCP must deal w/ that stateless nature.
Setup a playground project testing it out with focus on the issue and surpressing any further business logic...
I hope it helps....