I have to jump on this, come on! The wonderful "scalability" stuff jumps up again.
Scalability == ability to throw hardware at problem in order to handle more load. A reasonable measure of scalability is plotting the load volume (number of concurrent users, transactions per second, messages per second, whatever) against the hardware volume (I use volume as you can scale "vertically" instead of "horizontally" -- both have their place). The closer the function is to linear the better (unless you can find one which allows better-than-linear scalability, in which case please email me!).
Language, library, and platform are almost wholly irrelevent when it comes to scalability. This is almost pure system and application design stuff. Almost any significant application will have state -- heck even google does now (when you log in and get that customizable news page). State and I/OP are the usual killers of scalability. The problem is that the easiest way to fix one hurts the other. So, you play games =) I/O is, in the end, a harder problem, so most folks solve it first -- get big fat switches and lots of machines to spread the traffic around. This makes state way harder. Harder, but far from impossible.
A really nice "real world" write-up on state management growing pains comes out of a (so far) annual talk on LiveJournal (supposedly it gets 5 times the traffic as slashdot, and just referral traffic from slashdot is enough to kill at least 80% of web apps based on anecdotal evidence).
The solutions they talk about aren't the only way to go, but it is one with lots of detail publicly available, so it is a nice one to use as a reference. State management was killing em, basically. So, how do you manage state? The classic LAMP answer is "share nothing" -- which DHH talks about in a way I personally disagree with. To him "share nothing" means share nothing in memory between app server instance but go ahead and have shared state pushed out to some external repository. By that definition all the app servers he talks about which don't work that way (ie, the Java ones) in fact do -- use a RDBMS backed session store ;-) DHH's share nothing definition is a useful one though, as it is easy to do in any language or platform or framework or whatever. You still have shared state pushed to some other external resource. This is good.
Danga's answer is to push that shared state to memcached and accept the network hit to fetch it per-request. I rather agree with that option. Tangosol likes to adervtise a more sophisticated local/distributed cache setup and sticky sessions. That usually give better performance in exchange for slightly more complex deployment (you need sticky sessions). JGroups based distributed caches usually go for full replication, which is horrid for other reasons entirel =)
Notice not a word of what has been talked about here is language, platform, framework or whatever specific? That is because scalability issues are not framework or language specific. Does SISCWeb scale? That depends on how you design the system. It has nothing to do with SISCWeb.