English documentation is as follows:
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/deployment/deploy.html # wp1029629
The document set staging mode as follows
The following is part of the translation, given the standard of English, this translation is really bad, can only see their own to deal with
Nostage: Management Server (Administration Server) does not release copies of the documents, on the contrary, each target server must be through a single source folder to access this file and publish. The target server (target servers) on the stage directory in nostage mode will be ignored.
For example, if you publish a Java EE application to cluster three servers, then every one server must be able to access the same application file (from a shared network directory) to publish procedures
Note: Release the file from the nostage mode is a path, the path is released when a user (with the stage model contrast, stage models is the source of each stage of a server directory). Nevertheless, even in nostage mode, weblogic server, copy the part of the deployment to the temporary directory. This enables the user to update the whole file or part of the released documents released.
In nostage mode, web containers automatically detect changes in jsp or servlet. Nostage also allows you to later update only parts of an application by updating those parts in one file system location and then redeploying.
When posted to the management server only when the management console as the default value to use nostage mode. Weblogic.Deployer use the target server's staging mode (that is, the destination server to see what kind of model), the management server on the default nostage mode. If you are a host running a cluster, or through a shared directory you publish a very large applications to multiple hosts, then you can choose nostage mode. Published with nostage mode application will save a large release time, because do not need to copy files.
Stage: Management Server to the released files from the original position (in the management of the server) copy to the target server's staging directory. For example, if you use stage and release a Java EE application to the cluster of three servers, the management server in the cluster each server have a copy. Each server uses a local file copied to release Java EE applications.
There is a need for a place to live (personal records): In weblogic10 +, if you clear the cache of a server cluster, such as the server name appserver1, or remove the stage directory in the file, then the program does not automatically from the management server automatically synchronized to appserver1 the stage program directory, and only re-release program to the management server (the management server, if the re-released to appserver1 program, the program will not be copied to the stage directory), this program will be copied to the stage appserver1 catalog; another case, if I change the jsp in the source directory contents, then appserver1 will not synchronize the jsp file, must be artificial to appserver1 the stage directory to replace the jsp file can be up to date. This is a good use of nostage, see results immediately after the modification.
If you do not specify the staging directory, then the default directory is the stage:
· For exploded archive deployments, the deployment name and staging subdirectory are the name of the directory you deployed (physicianEar in the example above).
· For archived deployments, the default deployment name is the name of the archive file without the extension. For example, if you deploy physicianEar.ear, the deployment name and staging subdirectory are physicianEar.
When publishing to multiple weblogic instances when the management console uses stage mode as the default mode. Weblogic.Deployer use the target server's staging mode as the default, and the managed server using stage mode as the default.
Stage models make sure that each server has a local copy of release, such interruption as a network management server will not connect to other servers does not matter (because it uses the local release). If you're about to release a large application to the cluster of multiple servers, it will be time-consuming. Consider nostage mode to avoid copying large files to multiple servers and redundant move
External_stage: with the stage similar to the target server to use a local copy of the published application. However, the management server does not automatically copy the documents released to the destination server; the contrary, before the release, you must copy these files to each target server's staging directory. You can manually copy the implementation or use of automated scripts.
Within each target server's staging directory, deployment files must be stored in a subdirectory that reflects the deployment name. This can either be the name you type in for the deployment, or the default deployment name (the name of the exploded archive directory, or the name of the archive file without its file extension).
External_stage mode is the least common deployment staging mode. It is generally used only in environments that are managed by third-party tools that automate the required copying of files. You may also choose to use external_stage mode when you are deploying very large applications to multiple machines and you do not have a shared file system (and cannot use nostage mode). Using external_stage in this scenario decreases the deployment time because files are not copied during deployment.