My original port of Seaside (based on Seaside2.6) used the idea that you’d process a single request at a time, but allow more than 1 session to be handled by a vm, but the problem becomes that a single long running request can hog the vm and cause delays for the other sessions … the problem of overloading a single vm with active requests becomes even more pronounced when you only handle a single request at a time … so the approach was abandoned in favor of the commit/request idea. If you can guarantee short response times, then this approach reenters the realm of possible:)

I’ve done benchmarks where I’ve hit 1000 requests/second on 8 cpu hardware with 30g of ram and multiple disk spindles using the 1 commit/request model … no trickery, just throwing hardware at the problem.

Out of curiousity, what kind of request rates are you looking at in your application?

I admit that I have no idea if this scenario would be any better than the one you proposed in the post… I’m just going off of my experience with other frameworks and thought I’d ask.

I like the sound of 500 requests/second, if you’re hinting that you’re getting there. :) Has performance improved lately, or are you referring to the use of navigation URLs?

You can’t abort when starting to handle a request, because another request may be in progress, so a vm can only process a single request at a time.

In order to handle multiple sessions in a single vm without blocking, you have to be much more precise about where you abort and commit … you cannot safely abort when anyone else is in the process of looking at persistent data, because the act of aborting may change that data, this greatly restricts your ability to refresh your view. Commit conflicts become a problem to be reckoned with as well …

You can hit pretty acceptable request rates using the commit/request model. When shooting for rates above 500 requests/second, then you’ve entered the realm, where it may be worth taking a look at application specific transaction handling…

You’d have all of the advantages of what you described above (sessions not needing to be committed, but instead saved in local temp space) without extra process overhead from running a gazillion gems.