Hi Damitha, A couple of questions ...
> A service could support session by creating a hash table filling it with > key value pairs and setting it to the message context. > Since this is done at the service level - a higher level - I thinks its nicer to have a simple API call to set session data rather than having to create a new hash table and set that in the message context. (e.g. msg_ctx_set_session_data(key, value) or something like that) > Then it add the Set-Cookie header into the response message which has the > cookie header value of session id and expiration time. > Is the expiration time configurable? > In the client side the sessions are stored in a session map against the > server. > What do you mean by storing sessions against the server? Are there any plans to make the session data persistent so that we can have persistent sessions?. > Http Keep Alive support for Axis2/C client side. Do we support Keep Alive on the server side?. IIRC the HTTP transport receiver closes the connection on the server side?. >From there onwards it will reuse this http client for sending the messages. The main issue in reusing an HTTP client and hence the persisted connection is that in case the server goes down and maybe comes up again, the persisted connections that we have are no longer valid. If you now try to reuse these connections, the behavior is undefined. Therefore you have to do a socket select to check the validity of a persisted connection prior to reusing it. How do you handle this situation in your implementation?. Danushka -- Danushka Menikkumbura Technical Lead, WSO2 Inc. blog : http://danushka-menikkumbura.blogspot.com/ http://wso2.com/ - "The Open Source SOA Company"
