| <?xml version="1.0"?> |
| <document> |
| |
| <properties> |
| <title>OpenEJB Configuration</title> |
| <sub-title>Stateless SessionBean Containers</sub-title> |
| </properties> |
| |
| <body> |
| |
| <section title="Declaring your Container" ref-id="declare"> |
| <p> |
| Stateless SessionBean containers are defined using a <Container> element |
| with the <b>ctype</b> attribute set to <b>STATELESS</b>. |
| </p> |
| </section> |
| <section title="STATELESS properties" ref-id="properties"> |
| <p> |
| All Stateless SessionBean containers have the following properties |
| which you can override. If a property is not overridden, then the |
| default value is used. |
| </p> |
| |
| <section title="TimeOut" ref-id="STATELESS.TimeOut"> |
| <p> |
| Specifies the time to wait between invocations. This |
| value is measured in milliseconds. A value of 5 would |
| result in a time-out of 5 milliseconds between invocations. |
| A value of zero would mean no timeout. |
| </p> |
| |
| <p> |
| Default: |
| <code-block>TimeOut 0</code-block> |
| </p> |
| </section> |
| <section title="PoolSize" ref-id="STATELESS.PoolSize"> |
| <p> |
| Specifies the size of the bean pools for this |
| stateless SessionBean container. Each bean type gets it's |
| own pool. For example, if two ejbs are deployed into this |
| container, there will be to instance pools, one for each |
| ejb type. |
| </p> |
| <p> |
| Default: |
| <code-block>PoolSize 10</code-block> |
| </p> |
| </section> |
| <section title="StrictPooling" ref-id="STATELESS.StrictPooling"> |
| <p> |
| StrickPooling tells the container what to do when the pool |
| reaches it's maximum size and there are incoming requests |
| that need instances. |
| </p> |
| <p> |
| With strick pooling, requests will have to wait for instances |
| to become available. The pool size will never grow beyond the |
| the set PoolSize value. |
| </p> |
| <p> |
| Without strict pooling, the container will create temporary |
| instances to meet demand. The instances will last for just one |
| method invocation and then are removed. |
| </p> |
| <p> |
| Default: |
| <code-block>StrictPooling true</code-block> |
| </p> |
| </section> |
| </section> |
| |
| <section title="Examples" ref-id="examples"> |
| <section title="Basic Default" ref-id="example.default"> |
| <p> |
| Here is an OpenEJB config with a Stateless SessionBean Container using all |
| the default values. |
| </p> |
| <p> |
| <file name="openejb.conf"><![CDATA[ |
| <?xml version="1.0"?> |
| <openejb> |
| |
| <Container id="My Stateless Container" ctype="STATELESS"/> |
| |
| </openejb> |
| ]]></file> |
| </p> |
| </section> |
| |
| |
| <section title="Multiple Containers" ref-id="example.multiple"> |
| <p> |
| It may help application or team organization to define more than one Stateless |
| SessionBean container in your openejb.conf file and name then accordingly. |
| </p> |
| <p> |
| <file name="openejb.conf"><![CDATA[ |
| <?xml version="1.0"?> |
| <openejb> |
| |
| <Container id="Widget App Container" ctype="STATELESS"/> |
| |
| <Container id="Foo App Container" ctype="STATELESS"/> |
| |
| </openejb> |
| ]]></file> |
| </p> |
| </section> |
| |
| <section title="Overriding Properties" ref-id="example.properties"> |
| <p> |
| Anytime you want to change the way the container manages the beans |
| it runs, you simply need to override the corresponding property. |
| </p> |
| <p> |
| Here is an example of one Stateless Container with the PoolSize set |
| to 20 and another with it's PoolSize set to 200. |
| </p> |
| <p> |
| <file name="openejb.conf"><![CDATA[ |
| <?xml version="1.0"?> |
| <openejb> |
| |
| <Container id="Widget App Container" ctype="STATELESS"> |
| StrictPooling false |
| PoolSize 20 |
| </Container> |
| |
| <Container id="Foo App Container" ctype="STATELESS"/> |
| TimeOut 60000 |
| PoolSize 200 |
| </Container> |
| |
| </openejb> |
| ]]></file> |
| </p> |
| <p> |
| In the above example, the Widget conainer has shut off strict pooling, so |
| even when the pool has grown to the maximum (20), no one will have to wait for |
| an instance. As soon as each request finishes, the extra instances are removed. |
| </p> |
| <p> |
| The Foo container, on the other hand has not shut off strict pooling, so when the |
| pool has reached it's maximum (200), incoming requests will have to wait till |
| another request finishes and returns an instance to the pool. Since 200 instances is |
| a lot to keep in a pool when nothing is happening, we set the TimeOut to |
| 60000 milliseconds (1 hour). So, an hour after the last request comes in, the |
| container will start to shrink the pool down as much as possible. |
| </p> |
| |
| </section> |
| </section> |
| </body> |
| </document> |
