|
[
Permlink
| « Hide
]
Andrew Perepelytsya added a comment - 28/Oct/08 01:42 PM
My understanding was the opposite - sessions span multiple services during the flow, but they do not outlive connections.
Right, that's how they currently work, but that's what HTTP refers to as the request context, so maybe there's a confusion in terminology here. At any rate, I think something longer-lived would be useful in certain applications (security, BPM), regardless of what we call it.
Http session should behave as normal. the difference is that the HttpClient knows it needs to pass back the Session info (stored in cookies).
Just to be clear, Mule should not cache sessions, rather session info should be serialised with the current message and it is up to the client to ensure that the session info is passed back. This is how HTTP works and Mule should follow suit.
Dan, can you pick this up as part of the Acegi work?
After reading Ross' comments, I think I understand how sessions are supposed to work now, but I have created MULE-3982 for at least making this easier to understand (and making sure it works, as well).
Closing this since it apparently works as designed.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Major
Sessions in Mule do not really behave like sessions
