Creating database tables  Setting field-mapping properties

Chapter 27: Creating Entity Components

Configuring concurrency control

When using mapped fields, you must also choose a concurrency control model. Concurrency control prevents overlapping updates from entity instances running in different threads or different servers, or from applications running outside of EAServer. There are two approaches for concurrency control:

OCC allows greater scalability than PCC, however, when using OCC, client applications must be coded to retry rejected updates, or you must enable automatic transaction retry for the application components as described below.

When using OCC, each update statement contains SQL logic that determines if the last-read timestamp matches the stored value, and rolls back the transaction if the timestamp does not match. In other words, updates based on stale data are rejected. There are several options for using timestamps:

StepsEnabling optimistic concurrency control

  1. Configure the Timestamp field on the Persistence/General subtab. Table 27-1 describes the allowable values. For best performance when using tables with many columns or large column values (such as Sybase text or image columns), specify a timestamp column as described in Table 27-1.

    If multiple tables are used and you specify a timestamp column, all tables must contain a column with the same name and datatype.

    Table 27-1: Timestamp field values

    To configure

    Set the timestamp value to

    A timestamp column

    The name of a single column in each table that serves as the timestamp to detect update collisions. If the component uses multiple tables, each must contain a timestamp column with this name. The column type can be:

    • A 4-byte integer – this is the default timestamp column type. All processes that update the table(s) must increment the timestamp with each update, or your DBA can create an update trigger to increment the timestamp automatically.

    • The database timestamp type – you can use the timestamp datatype if using Sybase Adaptive Server Enterprise or Adaptive Server Anywhere version 7.0 or later. You must also define a field mapping property to specify the timestamp datatype as described in “Setting field-mapping properties”. For example, if the column name is ts, specify the mapping as:

      ts[dbts not null]
      

      dbts is a logical type name mapped to the timestamp type in the Sybase_ASE and Sybase_ASA database types. If the database does not support timestamps, a 4-byte integer counter is used instead.

    A table level timestamp

    A table and column name, in the form ts_table.ts_column, where ts_table specifies the timestamp table and ts_column specifies the name of the timestamp column in the timestamp table. The specified timestamp table must be separate from the main table. The timestamp tables can contain multiple columns, to allow use of one timestamp table by multiple entity beans. Timestamp tables are automatically created if they do not exist.

    A timestamp table can be shared among multiple components even when only one column is present in the timestamp table. In other words, a single timestamp value can be shared by multiple tables. This helps further improve performance for a group of read-mostly tables. However, any insert, delete, or update on any of the tables results in all cache entries being discarded.

    When using a timestamp table, database triggers are required to increment the timestamp for each update, delete, or insert to tables that are mapped to the component or components that require the timestamp. You can set the component property com.sybase.jaguar.component.ts.triggers property so EAServer creates triggers, create triggers yourself, or add code to existing triggers.

    All values comparison

    Leave blank.

  2. Optionally enable auto-retry for the application components so that EAServer replays EJB CMP transactions that fail due to conflicting updates. Auto-retry must be configured for the component that initiates the transaction, which is typically a session bean in EJB applications. Auto-retry works only for intercomponent calls, not for direct invocations of entity beans from the Web tier or base clients. Configure auto-retry as follows:

    Auto-retry is not appropriate for all applications. For example, an end user may want to cancel a purchase if the item price has risen. If auto-retry is disabled, clients must be coded to retry or abort transactions that fail because of stale data. The exception thrown is CORBA::TRANSIENT (for EJB clients, this exception is the root cause of the java.rmi.RemoteException thrown by the EJB stub).

  3. For EJB CMP entity beans, configure an effective transaction isolation level, as described in “Configuring CMP isolation level” in the EAServer Performance and Tuning Guide.

  4. Verify that the Select With Lock option on the Persistence/General subtab in the Component Properties dialog box is disabled. On the Advanced tab, verify that com.sybase.jaguar.component.selectForUpdate is not set or set to false.

StepsEnabling pessimistic concurrency control

  1. Configure a locking mechanism. You can do one of the following:

  2. Make sure that OCC is disabled by setting the Timestamp field to “none” on the Persistence/General subtab in the Component Properties dialog box.





Copyright © 2005. Sybase Inc. All rights reserved. Setting field-mapping properties