<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">This can actually be useful in larger systems where you are making use of heavily componentized code, but in some cases it does seem like overkill.</span></blockquote><div><span style="font-size:12.8px">That's close to the heart of the question. In larger systems, what is useful about the componentized session objects in particular (as opposed to components/adapters/interfaces in general)? It's a very particular API, so I guess there's a reason for that.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">As for persisting session data-- I guess the idea is that storing or retrieving the session object doesn't need to be async because it is just an object in memory corresponding to a cookie in the request.</blockquote><div><br></div><div>But doesn't that mean it's impossible to restart the process without destroying user session data? That doesn't seem ok. Isn't that a problem for your cas proxy?</div><div><br></div><div>Thanks Carl</div><div><br></div><div>DJM</div><div><br></div><div><br></div></div>