How can we configure correctly orion-ejb-jar.xml in our aplication for proper use of Entities Pooling?
We've follow the instructions in the orionserver.com's
docs and "www.atlasian.com" (http://kb.atlassian.com/content/orion/docs/deployment/orion-ejb-jar.xml.html)
and the server can't do nothing. Neither "max-instances="XXX" parameter
nor "exclusive-write-access="true", etc, see does nothing
<entity-deployment ...> Deployment info for an entity bean.call-timeout - The time (long millis in hex) to wait for an EJB if it is busy (before throwing a RemoteException, treating it as a deadlock). 0 equals "forever" and is the deafault. clustering-schema - The name of the data-source used if using container-managed persistence. copy-by-value - Whether or not to copy (clone) all the incoming/outgoing parameters in EJB calls. Set this to 'false' if you're certain your application doesnt assume copy-by-value semantics for a speed-up. The default is 'true'. data-source - The name of the data-source used if using container-managed persistence. exclusive-write-access - Whether or not the EJB-server has exclusive write (update) access to the database backend. If it does it will speed up common bean operations and enable better caching. The default is true. instance-cache-timeout - The amount of time in seconds that an entity is to be kept in the instance (assigned to an identity) state, specifying 'never' retains the entities forever. The default is 60. isolation - Specifies the isolation-level for database actions. The valid values are 'serializable', 'uncommitted', 'committed', 'repeatable_read'. location - The JNDI-name this bean will be bound to. max-instances - The number of maximum instances to be kept instantiated or pooled. The default is infinite. max-tx-retries - The number of times to retry a transaction that was rolled back due to system-level failures. The default is 0, ie no retries. name - The name of the bean, this matches the name of a bean in the assembly descriptor (ejb-jar.xml). pool-cache-timeout - The amount of time in seconds that an entity is to be kept in the "pooled" (unassigned) state, specifying 'never' retains the entities forever. The default is 60. table - The name of the table in the database if using container-managed persistence. validity-timeout - The maximum amount of time (in millis) that an entity is valid in the cache (before being reloaded). Useful for loosely coupled environments where rare updates from legacy systems occur. This attribute is only valid when exclusive-write-access="true" (the default). wrapper - Name of the Orion wrapper class for this bean. (internal server attribute, do not edit)
We have a j2ee aplication with a web module and various ejb modules
(mostly Entity BMP and various Sessions Stateless/Stateful).
Every JSP/Servlets obtain the Home and creates a Session EJB that realices
the Manager functions, but if we execute the same code repeatly,
every ejbFindByXXX( ) with the exactily identical parameters causes the
same ejbActivate() and ejbLoad() functions.
Seems that no entity pooling is done.
Another problem that we've is every call to "getXXX()" method causes
a "ejbStore()" of the Entity, and we've the "exclusive-write-access="true"
parameter in the orion-ejb-jar.xml. Now, we control with a "dirty flag"
when the objects is modified and then done the db update.
We've done a little test program that
1) Create 100 entity beans BMP from a JSP
2) Done a ejbFindByAll() and returns a Collection
of 100 EJBs
3) Invalidate the collection
4) repeat the 2 pass again,
And we show the time elapsed in each phase and there isn't any noticiable diference bettween pass 2 and pass 4, and we're configured correctly the orion-ejb-jar.xml for this Entity Bean.
Can anyone help us?
Thanks in advance.
PD: Excuse me for my bad english.
--
··································································································
Juan Manuel García
Essi Projects
Ingeniero de Desarrollo
t +34 977 221 182
[EMAIL PROTECTED]
f +34 977 230 170
http://www.essiprojects.com
http://www.edustance.com
··································································································
