XU services for execution
The XU retrieves rulesets and provides scalability.
On either engine, the XU provides a number of execution services such as engine pooling, ruleset sharing, XML or BOM conversion of the ruleset parameters, execution trace generation, monitoring and logging.
- Context pooling
All cache entries are linked to the JCA pool. All the XU resources are managed indirectly by the application server. Each rule engine is linked to a Service Provider Interface (SPI) connection, which is cached by the application server in the JCA pool. A ruleset is shared and kept in memory until no JCA connection references it. At the end of an execution session, the server can put the SPI connection back into the JCA pool. In this case, the associated rule engine is reset and ready for another execution.
Rulesets and rule engines are not preloaded before the first execution. The application server pools the connections according to the characteristics of the pool, which are defined in the application-server specific descriptor or in the administration console. By default, the maximum size of the connection pool for Java™ SE is 20.Restriction: You cannot change the size after you have set the initial value. You cannot change the maximum size of the connection pool after the XU starts.- Shared rulesets
- A ruleset can be shared by several rule engines. Likewise, any number of rulesets can be shared by more than one application so long as the classes used in the rules are available to each application. All dynamic classes are attached to the ruleset and are therefore made available directly to the XU. All Java classes are passed to the XU by the rule session class loader, which is by default the application class loader.
- Logging
- The way you change the default XU logging level depends on your application server, or whether you work in Java SE mode.