罗智强：依“管中闵案”道德标准 我要去告发蔡英文

Example Implementations

Examples of three-tier architecture implementation include the following:

• A Model-View-Controller Model 2 architectural design pattern that runs in a J2EE container with servlets and JSP that uses TopLink to access data without EJB.

• A Swing or Abstract Window Toolkit (AWT) client that connects to a server-side Java application through RMI, without an application server or container.

Advantages and Disadvantages

The three-tier Web application architecture offers the following advantages:

• High performance, lightweight persistent objects

• High degree of flexibility in deployment platform and configuration

The disadvantage of this architecture is it is less standard than EJB.

Variation Using Remote Sessions

TopLink includes a session type called remote session. The session offers the full session API and contains a cache of its own, but exists on the client system rather than on the TopLink server. Communications can be configured to use RMI or RMI-Internet Inter-Object Request Broker Protocol (IIOP).

Remote session operations require a corresponding client session on the server.

Although this is an excellent option for developers who wish to simplify their access from the client tier to the server tier, it is less scalable than using a client session and does not easily allow changes to server-side behavior.

For more information, see "Remote Sessions".

Technical Challenges

The three-tier application with a stateless client presents several technical challenges, including the following:

• Transaction management in a Stateless Environment

  A common design practice is to delimit client requests within a single unit of work (transactional session). In a stateless environment, this may affect how you design the presentation layer. For example, if a client requires multiple pages to collect information for a transaction, then the presentation layer must retain the information from page to page until the application accumulates the full set of changes or requests. At that point, the presentation layer invokes the unit of work to modify the database.

• Optimistic Locking in a Stateless Environment

  In a stateless environment, take care to avoid processing out-of-date (stale) data. A common strategy for avoiding stale data is to implement optimistic locking, and store the optimistic lock values in the object.

  This solution requires careful implementation if the stateless application serializes the objects, or sends the contents of the object to the client in an alternative format. In this case, transport the optimistic lock values to the client in the HTTP contents of an edit page. You must then use the returned values in any write transaction to ensure that the data did not change while the client was performing its work.

  For more information about locking, see "Configuring Locking Policy".

• External JDBC Pools

  By default, TopLink manages its own connection pools. You can also configure TopLink to use connection pooling offered by the host application server. This feature is useful for shared connection pools and is required for JTA/JTS integration (see "Configuring External Connection Pooling").

• JTA/JTS Integration

  JTA and JTS are standard Java components that enable sessions to participate in distributed transactions. You must configure TopLink to use JTA/JTS to use session beans in the architecture (see "Integrating the Unit of Work With an External Transaction Service").

• Cache Coordination

  If you choose to use multiple servers to scale your application, you may require TopLink cache coordination (see "Understanding the Cache").