First of all, if you were to attempt to run a debugger against a production machine in most shops I've worked in, management would be descend on you with fists and clubs (or the business equivalent). And in a lot of cases, I'd be one of the senior support persons who would also be extremely unhappy. I won't even let myself do that.
I design my webapps in such a way that the exact same WAR (or EAR) will run on a
test machine as it does on the production machine precisely so that when a production app breaks down I can replicate the exact code byte for byte on a "safe" platform. I realize that it's difficult, expensive and painful to replicate a large and complex database and/or a heavy workload in a test environment, but that's the kind of practice that distinguishes a true Enterprise operation from a bunch of school children playing programmer. Since the test and production servers should be using separate databases and other such services, the instance-specific configuration should all be coming from the application's deployment descriptor for that WLS instance, not hard-coded into the WAR or EAR.
I'm afraid that a single instance of WLS is expected to be the sole application running in its JVM and that a WLS instance cannot span over multiple JVMs. It's strictly 1-to-1, so again, you need to do your debugging on a test WLS instance. You DEFINITELY don't want production and test webapps running in the same WLS instance/JVM.
Beyond that, a remote debugger's breakpoints operate at the
thread level. If an application hits a breakpoint, that particular thread will suspend while you debug it, but all other threads continue running unless either A) they, too hit breakpoints or B) they go into a wait state waiting for action from one of your suspended threads. So technically, the rest of the server does continue to function normally.