Hi RajithaSorry for late reply :(pls see my comments below
Thanks,
Deepal
................................................................
~Future is Open~----- Original Message -----From: Rajith AttapattuSent: Monday, January 16, 2006 10:20 AMSubject: Re: Session Context
Hi Guys,,
I really need some help to figure out the following, and answers are greatly appreciated. These questions are based on discussions I had with Sanjiva regarding clustering. I will also start a different thread to discuss these points to get more input. Some of the questions will be very trivial, so pardon my ignorance.I really need the info for a prototype I am trying to implement. I can do it the hard way by going through all the code or take the easy route by simply picking your brain. I hope u guys want mind that.
1) If a service is deployed as Session Scope what is involved in terms of maintaining the session?
Some pointers to the code and a general description is great.>>>>>>>>>>>>>>>
Depending on the scope that ur service going to deploy , its ServiceContext will store in different locations , so the life time of the service implementation class will differ. As an example if ur service scope is TranportSession then ServiceConetext will be stored in SessionContext. And the life time of the ServiceConetxt will be the life time of the SessionConetext (in HTTP case it will be manage using HTTP cookies).
And if the service scope is application , then the life time of serviceContext will be same as life time of the entire system.
>>>>>>>>>>>>>
2)Is this working currently in Axis2 or yet to be developed? Any examples or doc on this will be great.
>>>>>>>>>It is implemented , but we do not have test cases to demonstrate this , but there is a sample called Calculator which uses application scope, I will try to write some test cases to show how to use sessions.
>>>>>>>>>>>>
3)What is the purpose of SessionContext ?? I assume it plays a major role in session scope, but to what extent?? Do u have the design or requirements that led to the existence of SessionContext.
If can I understand the original thinking behind it then I can have a better idea in terms of what should be distributable within the session context.>>>>>>>>>>>>>
well , that just to store transport level session . If you have close look at AxisServelet and SimpleHTTPServer you can understand that. At the transport level if the transport set the Session to the MessageConetext , instance dispatcher check for that to find servicecontext , if it is there it will use that , else depending on the scope , it will find the ServiceContext , and store it in the right location depending on the scope.
>>>>>>>>>>>>>>.
4) Exactly what will be stored within the SessionContext ??
Currentlly are we storing non-serializable information within the context that are ciritcal for a session?>>>>>>>>>>>
we are storing ServiceConetxt as well as ServiceGroup contexts in SessionConetxt , so that one HTTP session can interact with multiple service group in a system and use may use service group id to use write service group in addion to transport sessions. Using cookie id request will get its sessionContext if it present.
>>>>>>>>>>>
5)I assume the following relationship. ServiceContext holds several SessionContexts (multiple clients accessing the service with a session of their own). And SessionContext holds several Operational Contexts and in turn several MsgContexts.>>>>>>>>>
yes session context keep multiple servicecontext , but service context dose not keep its operation context or messageconetxt , those are stored in configuration context and will be removed from the configuration context when MEP is completed.
>>>>>>>>>.
Is this assumption correct?
Sorry for the long list, your help is really appreciated.
Regards,
Rajith Attapattu.
Thanks a lot for the comments from Ajith and Deepal. I have more questions regarding the issue.
1. Right now the session context is relevent only in http, since the concept of session is tightly coupled with the transport session (more specifically the HttpSession).
For arguments sake lets assume I try to make the SessionContext independent of the transport layer. In theory it's good architecture bcos then session scope services are not limited only to one transport, but in practice what sort of implications this will have within the current system??
What will be the impact?? and what considerations have to be made to ensure current functionality is not broken.
(Answers from desing point of view is good enough with a few pointers to source code)
2. What are the conerns and implications of using a SOAP header to be exchanged to maintain the session???
Will this be practical ??
Will this be a performance issue??
What sort of an impact does it have on the client side??
3. Using of cookies for session is subject to user enabling cookies. So is this a good stratergy ??? There are other ways to maintain session with async communication. For ex. ACT.
4. Deepal said
>>we are storing ServiceConetxt as well as ServiceGroup contexts in SessionConetxt , so that one HTTP session can interact with multiple service group in a >>system and use may use service group id to use write service group in addion to transport sessions. Using cookie id request will get its sessionContext if it >>present.
Now how big is this ServiceContext and ServiceGroup context(s) ??
If these objects are big and holds a lot of information and Assuming we cluster Session Context serialization/deserilization will be an expensive operation and moving across the wire will also be expensive and time consuming.
So eventually Axis2 might not scale very well in a clustered environment as replicating state will be expensive and time consuming.
I maybe wrong here about the assumptions I made about size and content of service ctx and servGrp ctx, so pls correct me.
Answers are greatly appreciated.
Rajith
On 1/17/06, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
