Architecture - eXist: A NoSQL Database and Application Development Platform - page 67

Each connection from an API to eXist is a single thread that interacts with the broker
pool , which is configured with a number of broker s (20 by default). Each broker is a
thread that interacts with the database, and represents a database request; this might
be a database update operation (add/delete/store/update) or a query operation
(XPath, XQuery, or XSLT). If you connect to eXist and all the brokers are busy, your
request will pause until a broker becomes available to service your request. Figure 4-2
shows this broker architecture.
Figure 4-2. eXist's broker architecture
If you are using eXist directly embedded within your own applica‐
tion, then you are responsible for deciding the threading model for
interacting with the broker pool.
The number of brokers available in the broker pool is configurable
in $EXIST_HOME/conf.xml , in the attribute located by the
XPath /exist/db-connection/pool/@max . You should configure the
number of brokers to be slightly higher than the expected number
of concurrent connections to eXist from your users.
Deployment Architectures
eXist offers many options for deployment. These options have informed the architec‐
ture of eXist, and your deployment scenario will determine how much or how little of
eXist you use and how the components of eXist are interconnected. eXist has three
main faces—the first you may see only if your interaction with eXist is as a software
developer, while the second two you may also see if you are an eXist user:
An embedded native XML database library
eXist can be compiled as a set of libraries that can be directly embedded into
your own application running on a JVM (Java Virtual Machine). In this instance
you talk directly to eXist via Java function calls. See “XML:DB Local API” on
page 366 and “Fluent API” on page 369 .