I was planning on making a caching mechanism on a user by user basis in SSJS (think userScope)/post it on my blog, but while I sketched the API, I ran into some issues.
In SSJS you have no way to bind callbacks (think event handlers) to the XPages life cycle. This can make the API quite IO heavy on servers with many users.
I've implemented something similar in Domino applications, and have gotten a big boost in performance. The current applicationScope makes it a little cumbersome (not a lot.. you have to write a wrapper for gets/sets that includes username in the scoped field) to cache lookups in applications with Readers fields. Another thing that I miss in the scopes as a caching mechanism is that the scoped variables only live as long as the application is active. In regards to performance/scalability, it would be nice to have caching mechanisms that lives beyond the applicationScope.
I posted a feature request on the XPages Extension Library's project page on OpenNTF.
If this is something that you would like/you have comments, please leave a response on the request, and maybe IBM will implement it :)
9 comments:
Tommy, wouldn't that be sessionScope? The runtime creates one instance per user (technically, per browser instance... if I'm accessing the same app via Chrome and Firefox at the same time, I have two different sessionScope instances).
We have several applications where one Domino user account has many flesh and blood users. sessionScope is per login(?).
Typically one user account per access level (be it document access, or access to functionality).
So.. It depends on the application/environment :)
Hum...so you want a "per user profile" type of scope so, right ?
Why don't you embed JEE caching libraries (such as ehcache) in your application ? It allows to cache objects using keys, and you can use whatever you want as a key. It also provides lot of built in features (expiration, refresh, even clustering etc...)
Michael Bourak
If I knew how to do that, I would write the userScope implementation myself, hence the request. If this is a niche requirement, the feature request will be declined.
If it's useless to the XPages developer community in general, I'll probably write a bean myself if/when I get the time/motivation to learn J2EE development.
"We have several applications where one Domino user account has many flesh and blood users. sessionScope is per login(?)."
Actually, no. It's per browser instance. I can login in from Chrome as Nathan, login from Firefox as Nathan, and have two totally different session scopes.
Register this as an application-scoped managed bean.
@Nathan: That was basically what I meant in my norwenglish :)
@Tim: Thanks! I will probably implement "NotesDocument persistence" for further gains in performance/decrease in IO, but it's a great starting point :)
For further performance gains at config lookups etc have a look at static classes and the singleton pattern, the JVM already has some powerfull features, saving you from manually caching stuff in the session (if the content is application - not user-specific)
using java directly instead of the SSJS hacks will make your life much easier and more fun
For config documents, I use Chris Tooheys/Nathan Freemans technique+a scoped map. When a field is fetched from config, it is put into the scoped map, so that the lookup only occurs when needed.
In the applications I develop, config documents only contain "small values". The performance I get from this is more than satisfactory :)
I plan on taking trying to write a bean implementation of the userScope tonight. Hopefully it's easier than it looks.
Post a Comment