CORBA 2.3.7 Programmer's Guide for Java

However, if the interface definition is changed to have one attribute, the client can send one
message to get all the information:
interface account {
struct CustomerRecord {
string name;
string address;
};
readonly attribute CustomerRecord customer;
} ;
Isolate CORBA functions and database access functions from business logic. Isolating CORBA
functions from non-CORBA functions is often referred to as delegation.
Independent data access objects (DAOs) allow SQL/MP and SQL/MX database accesses, which
are process-blocking operations, to be isolated from other functions that can be implemented using
multithreading. Data access objects can be implemented as context-free Pathway servers,
configured as server pools, that instantiate only one object per process and have the following
POA policy settings:
Lifespan policy
PERSISTENT
State policy
STATELESS
Threading policy
SINGLE_THREAD_MODEL
●
Use server pools to distribute objects and when possible, requests for the same object, across
processors, as described in Parallel Processing and Its Implications.
●
Ensure that the amount of data transferred with each remote operation is neither too large nor too
small.
●
Whenever possible, use data types that have low marshaling costs, such as primitive data types and
structs. Avoid using the any data type if at all possible.
●
Consider using fewer, larger CORBA objects (coarse object granularity).●
Parallel Processing and Its Implications
NonStop CORBA can run application servers as server pools. This style of implementation allows many
processes to act as one logical server; each new unit of work goes to the next available free server
process in the pool. Server processes can run in different processors to allow for parallel processing.
In general, the implementation of an object in a server pool is transparent to the programmer except for
the following characteristics: