8.12. Tuning a Container for Entity Bean Optimizations
JOnAS must make a compromise between scalability and performance. Towards this end, we have introduced some tags in the JOnAS-specific deployment descriptor. For most applications, there is no need to change the default values for all these tags. For a complete description of the JOnAS-specific deployment descriptor, see $JONAS_ROOT/xml/jonas-ejb-jar_4_0.xsd (http://jonas.objectweb.org/current/xml/jonas-ejb-jar_4_0.xsd).
8.12.1. Lock-Policy
The JOnAS ejb container can manage four different lock-policies:
- container-serialized
(Default.) The container insures the transaction serialization. This policy is suitable for most entity beans, particularly if the bean is accessed only from this container (shared = false).
- container-read-committed
This policy is also container-serialized, except that accesses of outside transaction do not interfere with transactional accesses. This can avoid deadlocks when accessing a bean concurrently with and without a transactional context. The only drawback of this policy is that it consumes more memory (two instances instead of one).
- container-read-uncommitted
All methods share the same instance (as with container-serialized), but there is no synchronization. This policy is interesting for read-only entity beans or if the bean instances are very rarely modified. It will fail if two or more threads try to modify the same instance concurrently.
- database
Let the database deal with transaction isolation. With this policy, you can choose the transaction isolation in your database. This may be interesting for applications that heavily use transactional read-only operations, or when the shared flag is needed. It does not work with all databases, and is expensive in terms of memory.
 | Note |
|---|---|
If you deploy CMP1 beans, you should use the default policy only (container-serialized), unless your beans are "read-only." In this latter case, you could use container-read-uncommitted. |
8.12.2. shared
This flag will be defined as true if the bean persistent state can be accessed outside the JOnAS Server. When this flag is false, the JOnAS Server can do some optimization, such as not re-reading the bean state before starting a new transaction. The default value is false if the lock-policy is container-serialized, and true in the other cases.
8.12.3. prefetch
This is a CMP2-specific option. The default is false. To optimize further accesses inside the same transaction, set the value to true to cache the data that is buffered after finder methods.
| Notes |
|---|---|
|
8.12.4. min-pool-size
This optional integer value represents the minimum instances that will be created in the pool when the bean is loaded. This will improve bean instance create time, at least for the first instances. The default value is 0.
8.12.5. max-cache-size
This optional integer value represents the maximum of instances in memory. The purpose of this value is to keep JOnAS scalable. The default value is "no limit." If you know that instances will not be reused, you should set a very low value to save memory.
8.12.6. is-modified-method-name
To improve performance of CMP 1.1 entity beans, JOnAS implements the isModified extension. Before performing an update, the container calls a method of the bean whose name is identified in the is-modified-method-name element of the JOnAS-specific deployment descriptor. This method is responsible for determining if the state of the bean has been changed. By doing this, the container determines if it must store data in the database or not.
| Note |
|---|---|
This is not required with CMP2 entity beans because the container does this automatically. |
8.12.6.1. Example
The bean implementation manages a boolean isDirty and implements a method that returns the value of the boolean isModified.
private transient boolean isDirty;
public boolean isModified() {
return isDirty;
} |
The JOnAS-specific deployment descriptor directs the bean to implement an isModified method:
<jonas-entity> <ejb-name>Item</ejb-name> <is-modified-method-name>isModified</is-modified-method-name> ..... </jonas-entity> |
Methods that modify the value of the bean must set the flag isDirty to true. Methods that restore the value of the bean from the database must reset the flag isDirty to false. Therefore, the flag must be set to false in the ejbLoad() and ejbStore() methods.
8.12.7. passivation-timeout
Entity Bean instances are passivated at the end of the transaction and reactivated at the beginning of the next transaction. In the event that these instances are accessed outside a transaction, their state is kept in memory to improve performance. However, a passivation will occur in three situations:
When the bean is unloaded from the server, at a minimum when the server is stopped.
When a transaction is started on this instance.
After a configurable timeout. If the bean is always accessed with no transaction, it may be prudent to periodically store the bean state on disk.
This passivation timeout can be configured in the JOnAS-specific deployment descriptor, with a non-mandatory tag <passivation-timeout>.
<jonas-entity> <ejb-name>Item</ejb-name> <passivation-timeout>5</passivation-timeout> ..... </jonas-entity> |
Example 8-1. Passivation timeout
This Entity Bean will be passivated every five second, if not accessed within transactions.