Sometimes I get to see the xPage code other developers made and a thing that still confuses a lot of people is how and when to use the correct scoped variables. Many times people just put everything into the sessionScope. Because it is easy ( its always there!) and it is personal (every user gets a different session) or is it? This blogpost is about the do’s and dont’s with scoped variables. How not to use them and how to use them. When to use them and when not to use them..
Choose the right scope.
Often developers use the session scope for everything they need to cache. Complete doccollection references disappear in the session scope, state variables are being saved in the sessionscope things that only should be used during a request end up in the session scope etc.. etc… . Many blogs already pointed it out but please try to use the correct scope for the job.
The lifetime of this scope is best defined as
“From the very first access of a user ( anonymous, or logged in) until the time the timeout has exceeded after the last visitor left the stage.”
Things you should add to this scope are :
- Settings everyone in your application need and don’t change often like database references, keyword values
- Managed beans which are used by all users. Such as objects who retrieve data from other systems, caching mechanisms, util classes etc.
This scope is a map of key/value pairs which is bound to each visitor. This makes this scope a good place to put stuff like
- User specific data such as a user bean, user profile documents, certain personalized documents etc.
Things you don’t want to store here
- Page states such as the state of a wizard you are currently servicing to the user
- keyword values, managed beans which are not bound to that specific user.
- Values set in field A on page A which are used by field B on page A
The viewScope is a xPage specific key/value map. This scope is ideal for saving view (page) specific state data. Such as:
- State variables which control hide/when of a certain part(s) of the page (panels, divs etc..)
- Model data you need access to during the lifetime of this page.
- Data you only need on this page and only this page for the current user.
The request scope is very short-lived scope. The values in this scope are only there during a single request. When another request is made the values previously declared are wiped. This scope is best used when you want to pass data during an event or want to store data which is used by multiple parts of your system during an single request.
Now you know what you should do with each scope ( more or less) one important lesson I learned is that you should be very carefull of the amount of data you put into scopes. Escpecially the session scope. Be aware of the fact that the session scope is user bound. If you have 10 users, these users all get their own scope. You decide that there should be 4 objects per user you end up with 40! objects stored.
Ofcourse this should not be a big issue what if they are 40 text strings consisting of each 10 charachters.. thiswould be a big issue. But if you decide to add lets say some caching system which caches a part of a view for each user just be aware that the amount of memory consumed can be more then you expected it to be. And whenever xPages (or the JVM to be precise) runs out of memory you will get a lot of debugging fun.
So keep in mind. When you need a knife.. don’t use a spoon.