The sessionScope variable can be a bit elusive. I have found the documentation to less than explicit and somewhat confusing. I am not an expert at the interworkings of the Domino server but here is what I have found.

1.  If a user logs out of Domino, then the same user or a new user logs back into Domino using the same URL it is possible that the sessionScope variables set by user! might be accessed by User2. So I have created a LogOut script that iterates through sessionscope.keySet() and removes the variable. Seems to work well and have no problems with this.

2.  If a user opens a Database using the URL http://Mysite.com/datbase1.nsf and then some sessionScope variables are set then is redirected to http://Mysite.com/database2.nsf this seems to be viewed by Domino as a new session and the sessionScope variables are lost. 

what I have done to "fix" the second issues is I store ALL XPages design in a single XPages database. So every URL starts with http://Mysite.nsf/XPagesMaster.nsf and the user always stays within the same session. I then store the actual data in one or more separate databases. Each of these dataBases contain the Native Notes Design items of Forms and Views but no XPages. Now say I have a Custom Control or XPage that displays a "view" of documents from one of the actual data stores you can point the dataSource either by hard code or programatically. This separation of code from the data has a lot of advantages. The data stores tend to be much smaller for example. 

Further, I have developed an applicationScope Managed Bean that stores information about each of the data store databases such as RepID, FilePath etc. This information is generally pretty static once your system is set so the applicationScope bean only gets loaded once per HTTP load. I load the bean from a series of configuration Documents that define each database. In my case I have perhaps 10 - 20 data store databases and several of them have very similar data so I can reuse the same custom control to display the data from several of the data stores simply by dynamically defining the data file path. 

.<xp:this.data>
       <xp:dominoView
                 var="vwCollection"
                 viewName="someviewname"
                 <xp:this.databaseName><![CDATA[#{javascript:appProps[sessionScope.ssApplication].getFilePath()}]]></xp:this.databaseName>
       </xp:dominoView>
</xp:this.data>

the applicationscope Bean is called appProps so by setting the sessionscope.ssApplication to some value appProps returns the FilePath of that database. assuming the viewName is the same in each instance. Simple way around that is to define a Custom Property on the control so the viewName could be  viewName="#{javascript:compositeData.dataView}" and now the custom Control is really reusable.

Hope this helps. 

Bill provides a great response.  

To sum up his first point I would just say that sessionScope is really a "Browser Session" and not a "User Session" which is what people commonly think of it as.

sessionScope is also specific to the .nsf file. What Bill is doing is putting all the code in 1 .nsf file and then using x number of other .nsf files to act as data stores.  I consider this the Best Practice for ANY XPages application.  Even it's it's just 1 data store .nsf.  This is how it SHOULD be done in my opinion.  The data stores hold the documents and views.  TECHNICALLY speaking the forms are optional.  They're really not needed but are at least nice to have.

I almost always add the dataSource to a panel inside the Xpage or Custom Control. Sort of don't define it until you need it.