The Windows file system is extremely aggressive about holding onto file locks for open files - this makes it effectively impossible to redeploy webapps into Tomcat reliably on a Windows platform (although in practice if you're not using JSF, which is often locked permanently, you should be able to redeploy after a delay of 1 minute).
If you are developing on Windows, you will want to add the "antiResourceLocking" attribute to your base context file context.xml in $CATALINA_HOME/conf, so that it reads as so:
<!-- The contents of this file will be loaded for each web application -->
<Context antiJARLocking="true" antiResourceLocking="true" >
<!-- Default set of monitored resources -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<!-- Uncomment this to disable session persistence across Tomcat restarts -->
<!--
<Manager pathname="" />
-->
</Context>
The "antiJARLocking" attribute is probably unnecessary. These options are documented on the Tomcat site at http://tomcat.apache.org/tomcat-5.5-doc/config/context.html#Standard%20Implementation. Note that the way this option works is to make a completely clean copy of the entire webapp into a private "temp" directory whenever it detects a redeploy. This in theory will slow up deployment and chew up disk space, but in practice on modern machines the delay is barely noticeable, even when deploying bulky things like Sakai. You will clearly want to turn this option off in production though. Also remember to look into $CATALINA_HOME/temp and clean it out from time to time, since the same resource locking issues prevent Tomcat from being able to delete stale versions of your webapps 
There are small restrictions apparently on not being able to get certain kinds of resource paths to webapp resources for webapps that are being run from the special "temp" area but I have never run into them in practice.