Using ModeShape in web applications is a powerful way to persist information, especially since the hierarchical nature of ModeShape maps very well to URLs. How your web application uses Sessions depends a little on how the web application works. But the usual rules about not using a Session in multiple threads and long-running Sessions still apply here.
It's very easy to use sessions in web applications or services that are stateless: simply obtain a new Session for each request, use it to read/change content, save any changes, and then close the session.
Creating a new Session is very lightweight, and it's easier and likely faster than trying to maintain a pool of active Sessions. It also means your application or service can authenticate the Session with the user making the request.
If you can make your web application or service stateless, then just do it. Stateless web apps are always simpler and easier to scale .
In a stateful web application,s clients can interact with the server across multiple HTTP requests. These kinds of applications are more complicated, but very useful if you have to have this behavior. If possible, try to design your web application so that (just like stateless web applications) the application handles each HTTP request by using a new Session, reading/changing content, saving any changes, and then closing the session.
Sometimes that won't be possible, and you'll need to associate a single Session with the HTTP session. In this case, each HTTP request that is part of the same HTTP session will read/change content, and one (or more) of the requests will ultimately save any changes. Be sure to always close the Session when the HTTP session ends (this can be tricky).
Be aware, however, that Session instances are not serializable, so this using a single Session for each HTTP session is really only useful if you're using session affinity. That way, all client requests that are part of the same HTTP session are handled by the same server (and thus Session instance).