The only other scheme I know of to defend against XSRF is to generate secret values for every request, which is not always practical.
You don't need to generate per-request tokens unless you want to; the token is simply yet another thing you stick into the session store and splash out onto the rendered page.
(Also, as my colleague Cory points out: if an attacker can influence the ACTION attribute of the form in any way, you've just coughed up your session token to an attacker in the name of blocking CSRF; is the risk worth the reward?).
I don't like keeping per-request state on the server, else I would use random CSRF tokens.
What are you talking about "if an attacker can influence the ACTION attribute of the form"? If they are running JavaScript in your DOM you are already hosed, they can grab any token you put in your form. There is no sane reason for having ACTION change via request parameters: you would have bigger issues than session stealing. And in any other situation, you should be protected by the browser's cross domain restrictions. I don't understand what you are suggesting.