What do you mean by "Embedded Tomcat"? To mean that means the Tomcat that's running inside the JBoss AS, in which case TA == JA and TB == JB.
I use the term embedded tomcat due to article at http://www.jboss.org/wiki/Wiki.jsp?page=TomcatStandalonevsEmbedded
Title of that article is:
What are the advantages and disadvantages of using Tomcat embedded inside of JBoss Application Server versus running Tomcat independently?
I want that behaviour, it is certain that we can do that with independently running tomcats. But what about with embedded tomcats?
Since Apache will check execution of Tomcat, it may send a request to TB. But TB will fail to serve since JB is not working in the assumuntion I did.
So will the TB request from JA?
OK. I'm going to be clarify terms a bit then, since "JBoss Application Server" includes the embedded Tomcat and is not a separate and distinct thing.
I think what you are talking about is the web tier within JBoss AS and the EJB tier within JBoss AS.
They both run in the same process so when thinking about this you would want to consider why the EJB tier would have failed when the web tier hasn't, and whether that failure would be something that would cause an EJB request made by the web tier to fail over. Failover only occurs when the EJB client (in this case in the web tier) determines that an invocation it's made has not successfully reached the server (in this case the EJB tier in the same process.) Normally this means some sort of communication problem has occurred. A problem in the EJB itself (e.g. its in some state where it's throwing exceptions, or invocations to it are deadlocking or whatever) does not trigger a failover. So, if the EJB client and the EJB server are in the same process, the odds of problems occurring that would trigger failover are not high.
Now, to answer your question: JBoss EJB clients include logic that detect whether the EJB being invoked upon is running in the same VM. If it is, the logic that causes a remote invocation on the bean is bypassed so the call can use call-by-reference and avoid expensive and unnecessary serialization/deserialization. Part of the logic that is bypassed is the clustering logic that provides failover. So, bottom line is you won't get failover.
You can alter this behavior such that the client will allow the call to go remote even though the target bean is running in the same VM. This comes up from time to time on the forums; search around a bit; how to do it is explained a few times. I think I wrote a post about a month ago describing it. :) But, we generally don't recommend doing this, as it adds major overhead to your application -- forces serialization/deserialization and causes calls to go over the network to other VMs when there is a perfectly healthy bean running in the same VM.
Thank you for your detailed explanation, now it is clearer.