Using External_Stage can we specify a location other than staging dir

Question

While using external stage mode for weblogic(I am trying for weblogic92)we must manually copy the deployment files(web app) to the staging directory of each target server before deployment.
Is there a option to copy the deployment files to another location other than Server's staging directory? To be more specific can I specify a location which is outside the server?
Secondly, with no-stage option of weblogic we can have a external location for the web application, but in case of the cluster,
this location has to be either shared or
the secondary node should have the same location(path to the web application) as that of the primary server.
Here is my config.xml entry of the primary node.
<app-deployment>
<name>TestWebApp</name>
<target>TestCluster</target>
<module-type>war</module-type>
<source-path>C:\TestWebApp\TestWebApp.war</source-path>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode>nostage</staging-mode>
</app-deployment>
Here there is only one source path for the entire Cluster. So if both of the server nodes have a valid location(C:\TestWebApp\TestWebApp.war), then the deployment will be fine on a running server. But on the second server node, if the Web app does not exists on that location, deployment will fail.
When we share the location the concept of cluster is lost. If go with the second option then the user is restricted to have the same path on second node also.
Is there any way to specify differnt locations(of the same web app) for different servers in the Cluster?

Answer 1

A few points of clarity:
1) Session starts in consumer group LOGIN_GROUP. That does not have session queueing since queueing sessions at log on time results in the user experience of a hung session, which we cannot have. Whether service X is used to get it there or something besides services is fine; how is not a concern at this point.
2) Session moves to consumer group MAIN_GROUP after about 5 CPU seconds in the LOGIN_GROUP. We want to do this because the MAIN_GROUP has session queuing, which we want for most sessions after they have the unqueued login experience per point #1.
3) Session moves to consumer group SLOW_GROUP after about 60 CPU seconds in the MAIN_GROUP (or some number of seconds; exact numbers are not the main focus here). We want this because we want long-running queries to be downgraded. However, we don't want to leave the session there since the query is the thing that is running long, so we want the session to get back to MAIN_GROUP when it is done. However, if we use SWITCH_FOR_CALL when going to the SLOW_GROUP, it will switch back to the LOGIN_GROUP. Which is the trouble--LOGIN_GROUP is an unqueued group, so we don't get the desired session queueing.
4) The solution must be fully automated without any DBA intervation or application code. We cannot use appliation code as this solution is intended for BI users working in tools that have direct data access. Thus prevents the use of DBMS_SESSION as you stated in your posts. How would we do that switching in an automated fashion without application code?
5) We cannot put the DBMS_SESSION commands in a login trigger since that would switch groups to MAIN_GROUP and would again run the risk of queueing a session at login, which feels like a hung session to users and results in a bad user experience and help desk calls.
Thanks!