Request forwarding enables data requests to be serviced
by a site that is geographically closest to the object store database.
With request forwarding, a Content Platform Engine server
communicates with an object store database over a local high-speed
LAN instead of a remote server accessing the object store database
over a lower-speed WAN, thus reducing network traffic and improving
performance.
The following figure illustrates this process:

In this example, Site B (with request forwarding enabled) forwards
a GetObjects request for 1001 objects to Site A. This request results
in 1001 round trips between the server and the database in Site A
over a high-speed LAN to collect the GetObjects request's result set,
and a single round trip over the slow-speed WAN from Site B to Site
A.
In contrast, Site C does not have request forwarding enabled. Site
C must service the GetObjects request locally, which results in 1001
round trips from Site C to the database in Site A across the slow-speed
WAN in order to collect the same result set.
By servicing the database request locally across the high-speed
LAN, and returning the result in only one round trip across the WAN,
network traffic is reduced and performance is increased.
Request forwarding has the following characteristics:
- Request forwarding must be enabled at the site level (both for
forwarding requests and for receiving forwarded requests), and each
server within the site must have a Request Forwarding Endpoint defined
for it to be able to receive forwarded requests.
- A site can be configured to enable requests to be forwarded to
another site (as in the previous bullet), but it can also be configured
to not accept any incoming requests. This allows accepting requests
to be disabled at the site level and eases server maintenance.
- Requests that are not specific to an object store, such as retrieving
GCD objects, are handled locally and never forwarded.
- GetObjects, GetSearchMetadata, ExecuteChanges, and ExecuteSearch
requests can involve one object store or multiple object stores. In
either case, the request can be handled locally or forwarded to an
object store in the site that is referenced frequently. However, a
request is never broken up, parceled out to multiple object stores
and then reassembled, even if this results in some database calls
being sent across a WAN.
- Content-related requests such as GetContent, PutContent, and MoveContent,
are never forwarded. In the case where there is no content cache present,
the local object store retrieves the security and content elements
from the remote database server and retrieves the content directly
from the remote server.
- If an incoming set of requests accesses multiple object stores,
and any request accesses an object store in the current site, the
request is not forwarded.
- If an incoming request arrives over the Java™ technology Enterprise JavaBeans (EJB) transport for a server
that does not support forward over the EJB transport, the request
is handled by the local server.
- There is no performance impact in the case where no additional
sites have been defined; for example, only the default site exists.
- If a request has been forwarded to another server, that server
makes no attempt to forward the request again.
- Request forwarding is across the EJB transport layer only.
- Request forwarding is only supported across homogeneous application
servers. Request forwarding across different application server vendors
is not supported.