This is a feature of JBuilder Enterprise.
The CMP Table Properties dialog box lets you set and modify the container-managed persistence (CMP) properties for a table in your schema.
To display the CMP Table Properties dialog,
Note: The properties displayed in the dialog box are relevant only to the Borland Enterprise Server.
Property | Description |
---|---|
getPrimaryKeyAfterInsert | Specifies the SQL the CMP engine executes to generate a primary key after the next INSERT. The CMP engine updates the entity bean with this primary key value. For more information about primary key generation, see the /BorlandEnterpriseServer/examples/ejb/pkgen example. |
getPrimaryKeyBeforeInsert | Specifies the SQL the CMP engine executes to generate a primary key when the next INSERT occurs. The CMP engine updates the entity bean with this primary key value. This property is usually used in conjunction with Oracle Sequences. For more information about primary key generation, see the /BorlandEnterpriseServer/examples/ejb/pkgen example. |
useGetGeneratedKeys | Use JDBC3 Statement.getGeneratedKeys() to populate
the primary key from autoincrement/sequence SQL fields. The default value is
false. The JDataStore 5 database supports this feature for its
autoincrement fields. For JDataStore 5 tables, the createColumnSql
property for the primary key must also be set to int autoincrement or
long autoincrement for this to work. |
jdbcAccesserFactory | Specifies a factory for a user-implemented instance of the com.inprise.ejb.cmp.JdbcAccessor interface. This interface gives you a way to write specific code to get a value from a java.sqlResultSet or to set a value to a java.sql.PreparedStatement . The default value is none. |
optimisticConcurrencyBehavior | You can specify one of the following:
UpdateAllFields - Issues an update on all fields, regardless of whether they were modified. Given a CMP bean with three fields: "key", "value1" and "value2", stored in a table called "MyTable", the following update will be issued at the end of every transaction, regardless of whether the bean was modified: UPDATE MyTable SET (value1 = <value1>, value2 = <value2>) WHERE key = <key> UpdateModifiedFields -This is the default setting. Issues an update only on the fields that were modified, or suppresses the update altogether if the bean was not modified. With the above bean, if only "value1" was modified, the following update is issued: UPDATE MyTable SET (value1 = <value1>) WHERE key = <key> This can give a significant performance boost for following reasons: 1) Often your data access is read-only. In such cases, not sending an update to the database is desirable. Borland has seen great performance boosts from this single optimization. 2) Many databases write logs depending on which columns were modified. For example, SQL Server will log the update if a TEXT or IMAGE field is updated, regardless of whether the column's value actually changed. Note that the database often does not (or cannot) distinguish between updating a column to hold the same value it used to hold (which is what occurs with "UpdateAllFields"), and actually modifying the column's value. Suppressing the update for the case where the value did not actually change can have a very significant performance impact when using such DBMSs. 3) There is less JDBC-based network traffic going to the database and less work going on in the JDBC driver. The network issue is, generally, not significant, but the JDBC driver issue is significant. Our performance measurements indicate that as much as 70% of the CPU's time is spent in the JDBC driver in large-scale EJB applications. Often, this is due to the fact that many commercial JDBC drivers have not been sufficiently performance tuned. Even for well-tuned drivers, the less work they have to do, the better. VerifyModifiedFields - In this mode, the CMP engine issues a tuned update while verifying that the fields it is updating are consistent with the values that were previously read in. So, for the previous example, where only "value1" was modified, the following update is issued: UPDATE MyTable SET (value1 = <value1>) WHERE key = <key> AND value1 = <old-value1> VerifyAllFields - This mode is similar to VerifyModifiedFields, except that all fields are verified. So the update would be: UPDATE MyTable SET (value1 = <value1>) WHERE key = <key> AND value1 = <old-value1> AND value2 = <old-value2> These two verify settings can be used to replicate the SERIALIZABLE isolation level in the Container. Often your application requires serializable isolation semantics. However, asking the database to implement this for you can have a significant performance impact. Borland tests show using SERIALIZABLE with Oracle instead of a less restricted isolation level, can slow down an application over 50%. The main reason for this slowdown is that Oracle provides optimistic concurrency using a row-level locking model. With the above two settings, you are basically asking the CMP engine to implement optimistic concurrency using field-level locking. And with any concurrent system, the smaller the granularity of the locking, the better the concurrency. |
datasource | Specifies the JNDI data source name of the database for this table. |
primaryKeyGenerator | Specifies a class, written by the user, that implements the com.inprise.ejb.cmp.PrimaryKeyGenerator interface and generates primary keys. For more information about primary key generation, see the /BorlandEnterpriseServer/examples/ejb/pkgen example. |
For more information about these properties, see the Borland Enterprise Server documentation.