Advanced Entity Bean Features
In WebLogic Server 8.1, BEA provides several new features and enhancement to support EJBs in general. In this section, we discuss the ones that apply to Entity beans.
Automatic database detection—
WebLogic Server can query the database to detect which kind of database is being used. If the database detected isn't the same as the database specified in the database-type element of the weblogic-cmp-rdbms-jar.xml file, preference is given to the type defined in the deployment descriptor.
Automatic table creation—
WebLogic can create the database tables or update them based on the deployment descriptors. This enables developers to manipulate the database structure without having to know how to do so in the context of the database. Developers can choose to disable this feature or specify what operations to support, such as CreateOnly, DropAndCreate, DropAndCreateAlways, and AlterOrCreate. You can also specify your own DDLs (database scripts) to create these tables. This is done through the tag <create-default-dbms-tables> of weblogic-cmp-rdbms-jar.xml.
Automatic primary key generation—
WebLogic supports automatic primary key generation for various databases. It also supports database-specific methods, such as Oracle sequences and the Identity column on Microsoft SQL Server. In addition, WebLogic supports using a specific table defined by the bean developer. This is done using the <automatic-key-generation> tag of the weblogic-cmp-rdbms-jar.xml file.
This feature can be used to delete dependent objects in one-to-one and one-to-many relationships. Cascading delete is not supported for many-many relationships. This can be used two ways:
Using the <cascade-delete> tag of ejb-jar.xml. This deletes the dependent records in memory and explicitly in the database.
Using the <db-cascade-delete> tag of weblogic-cmp-rdbms-jar.xml. This deletes only the dependent records in memory; the database has to be configured to delete rows automatically.
Preventing deadlocks for CMP beans—
With the cascading delete feature, deadlocks are more of a problem. This is more common when transactions use concurrent strategies. You can specify a lock order attribute in the deployment descriptor to prevent this problem. Use the <lock-order> tag in weblogic-cmp-rdbms-jar.xml.
Granular redeployment of EJBs—
You can specify that only the bean class can be redeployed, instead of having to redeploy the entire EJB. However, if the Home or Remote interfaces changes, the entire EJB does have to be redeployed.
WebLogic Server provides improved performance for EJB bulk updates, optimistic concurrency, field groups, relationship caching, and EJB redeployment. The Administration Console also allows more fine-grained monitoring and testing of the EJBs.
Constraining optimistic row checking—
You can specify the rows in a table that the EJB container should check when optimistic concurrency is used. Then using the new verify-rows element in weblogic-cmp-rdbms-jar.xml enables you to choose between optimistic checking on any row read by a transaction versus only rows updated or deleted by a transaction.
SQL query order optimization—
WebLogic automatically orders the select, update, insert, and delete queries to avoid integrity violations. This would also minimize deadlocks.
The queries are run in batch mode whenever possible. This helps to improve performance.
In addition to the new features in WebLogic Server 8.1, it's interesting to see the various tools that are provided.