web server - Borland Technical Publications

web server - Borland Technical Publications web server - Borland Technical Publications

techpubs.borland.com
from techpubs.borland.com More from this publisher
12.11.2014 Views

Complete Index of EJB Properties Table 31.2 Entity Bean properties (continued) Property Type Description Default ejb.findByPrimaryKeyBehavior Enumeration (Verify, Load, None) This flag indicates the desired behavior of the findByPrimaryKey method. The values are: Verify: This is the standard behavior, for findByPrimaryKey to simply verify that the specified primary key exists in the database. Load: This behavior causes the bean's state to be loaded into the container when findByPrimaryKey is invoked, if the finder call is running in an active transaction. The assumption is that found objects will typically be used, and it is optimal to go ahead and load the object's state at find time. This setting is the default. None: This behavior indicates that findByPrimaryKey should be a no-op. Basically, this causes the verification of the bean to be deferred until the object is actually used. Since it is always the case that an object could be removed between calling find and actually using the object, for most programs this optimization will not cause a change in client logic. ejb.checkEx istenceBefo reCreate Chapter 31: EJB, JSS, and JTS Properties 341

Complete Index of EJB Properties Table 31.2 Boolean Entity Bean properties (continued) Property Type Description Default Most tables to which entity beans are mapped have a Primary Key Constraint. If the CMP engine attempts to create a bean that already exists, this constraint is violated and a DuplicateKeyException is thrown. Some tables, however, do not define Primary Key Constraints. In these cases, the checkExistanceBeforeC reate property can be used to avoid duplicate entities. When set to True, the CMP engine checks the database to see if the entity exists before attempting the insert operation. If the entity exists then the DuplicateKeyException is thrown. Message Driven Bean Properties False Table 31.3 Message Driven Bean properties Property Type Description Default ejb.mdb.use_jms_threads Boolean Option to switch to using the JMS providers dispatch thread rather than the Container managed thread to execute the onMessage() method. For OpenJMS this value will be true, since the message will be delivered in the JMS providers dispatch thread. ejb.mdb.local_transaction_opt imization ejb.mdb.maxMessagesPerServerS ession Boolean Integer This property is currently used only with OpenJMS. It is used to attain atomicity without using the XAConnectionFactory. The same database is used for message persistence and application data. For JMS providers that support the option to batch load a ServerSession with multiple messages, use this property to tune performance. false Note This value will be true by default for OpenJMS. true 5 342 BES Developer’s Guide

Complete Index of EJB Properties<br />

Table 31.2<br />

Entity Bean properties (continued)<br />

Property Type Description Default<br />

ejb.findByPrimaryKeyBehavior<br />

Enumeration (Verify,<br />

Load, None)<br />

This flag indicates the<br />

desired behavior of the<br />

findByPrimaryKey method.<br />

The values are:<br />

Verify: This is the standard<br />

behavior, for<br />

findByPrimaryKey to<br />

simply verify that the<br />

specified primary key<br />

exists in the database.<br />

Load: This behavior causes<br />

the bean's state to be<br />

loaded into the container<br />

when findByPrimaryKey is<br />

invoked, if the finder call is<br />

running in an active<br />

transaction. The<br />

assumption is that found<br />

objects will typically be<br />

used, and it is optimal to<br />

go ahead and load the<br />

object's state at find time.<br />

This setting is the default.<br />

None: This behavior<br />

indicates that<br />

findByPrimaryKey should<br />

be a no-op. Basically, this<br />

causes the verification of<br />

the bean to be deferred<br />

until the object is actually<br />

used. Since it is always the<br />

case that an object could<br />

be removed between<br />

calling find and actually<br />

using the object, for most<br />

programs this optimization<br />

will not cause a change in<br />

client logic.<br />

ejb.checkEx<br />

istenceBefo<br />

reCreate<br />

Chapter 31: EJB, JSS, and JTS Properties 341

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!