|
|
|
|
|
|
|
|
|
|
|
| Refresh period | |
|
|
|
|
|
|
|
|
| |||||
TABLE | (Continued) |
|
|
|
|
|
|
| |||||
| Cache Settings |
|
|
|
|
|
| Pool Settings |
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| cache- |
|
|
|
|
|
|
|
|
|
|
|
|
| idle- |
|
|
| refresh- |
|
|
|
|
|
| cache- |
|
| timeout- |
| removal- | victim- | period- |
| pool- | max- |
| |
Type of | resize- |
| max- cache- | in- |
| timeout- in- | selection- | in- | steady- | resize- | pool- |
| |
Bean | quantity |
| size | seconds |
| seconds | policy | seconds | quantity | size |
| seconds | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Entity | X |
| X | X |
| X | X |
| X | X | X |
| X |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Entity | X |
| X | X |
| X | X | X | X | X | X |
| X |
Read- |
|
|
|
|
|
|
|
|
|
|
|
|
|
only |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Message |
|
|
|
|
|
|
|
|
| X | X |
| X |
Driven |
|
|
|
|
|
|
|
|
|
|
|
|
|
Bean |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Commit Option
The commit option controls the action taken by the EJB container when an EJB component completes a transaction. The commit option has a significant impact on performance.
There are two possible values for the commit option:
■Commit option B: When a transaction completes, the bean is kept in the cache and retains its identity. The next invocation for the same primary key can use the cached instance. The EJB container will call the bean’s ejbLoad() method before the method invocation to synchronize with the database.
■Commit option C: When a transaction completes, the EJB container calls the bean’s ejbPassivate() method, the bean is disassociated from its primary key and returned to the free pool. The next invocation for the same primary key will have to get a free bean from the pool, set the PrimaryKey on this instance, and then call ejbActivate() on the instance. Again, the EJB container will call the bean’s ejbLoad() before the method invocation to synchronize with the database.
Option B avoids ejbAcivate() and ejbPassivate() calls. So, in most cases it performs better than option C since it avoids some overhead in acquiring and releasing objects back to pool.
However, there are some cases where option C can provide better performance. If the beans in the cache are rarely reused and if beans are constantly added to the cache, then it makes no sense to cache beans. With option C is used, the container puts beans back into the pool (instead of caching them) after method invocation or on transaction completion. This option reuses instances better and reduces the number of live objects in the JVM, speeding garbage collection.
Determining the best commit option
To determine whether to use commit option B or commit option C, first take a look at the
Chapter 3 • Tuning the Enterprise Server | 57 |