Good question... With the decline in server-generated HTML, the session state can be shuffled outside the server app:
* Client UI state is kept on the client (browser, mobile app) * Security state (authentication, roles) is restored based on a client-passed token either from a server DB or by decoding the token itself (see JWT - JSON Web Token). The traditional session approach is still possible, just more rare. Most engines still have an underlying HttpSession object mandated by the Servlet spec. With this you have two options: 1. Keep the state in memory on a single server and configure the load balancer to route each client to their assigned instance. This doesn't protect against server failures, but at the same time it is easy and lightweight. 2. You can make HttpSession persistent and replicated across the cluster, like the appservers of old did. Lots of overhead for very little gain, but still possible with (embedded) Jetty, Tomcat and others. I certainly prefer stateless apps, and strongly dislike opaque sessions carrying around megabytes of garbage, due to developers having a hard time tracking reference chains of their objects. Worst case scenario I'd go with session routing via load balancer (#1 above). Andrus > On Feb 16, 2020, at 12:29 PM, Gino Pacitti via Webobjects-dev > <webobjects-dev@lists.apple.com> wrote: > > Thanks for everyones thoughts on the subject. > > I tried out Bootique and Spring Boot and worked around a few demos and > scenarios. > > What I don’t seem to understand yet is instance management? > > How do you manage sessions across instances of these ioc containers that seem > to be standalone web server and resource handlers… > > Any illuminating comments appreciated.. > > Gino _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
