There are often scalability talks about wicket and several users
(thousands). The fact is that Wicket is a tempting framework to use for any
project even websites and not neccesarily intranet applications. Now we all
know that Wicket uses session heaviliy making it memory demanding. But my
if you have your database caching worked out (if you cache db objects)
then adding more memory is also easy by placing more servers and use sticky
sessions that are round robin assigned to servers
you also then have fail over for free
the biggest bottleneck will be the database and the right
First, the 16000 sessions for a server is a highly theoretical. I
can't imagine single machine that would be able to handle 16000
concurrent request (while of course doing some meaningfull processing,
like updating database...)
With Wicket 1.3, stating that memory is the scalability blocker is
In my company , we built a really nice employment exchange with wicket and
we cant wait to launch it. But we need to know that assuming one sticks to
the best design practice of wicket (using detachable models everywhere and
stateless pages where necessary), is it so much memory and processors
