Advanced Topics - eXist: A NoSQL Database and Application Development Platform - page 447

Autodeployment
The trigger org.exist.repo.AutoDeploymentTrigger is used to install any new
EXPath packages into the database that have been placed into $EXIST_HOME/
autodeploy . This ensures that the latest packages are available when the database
is started.
Message receiver
For the emerging database replication support in eXist, the trigger
org.exist.replication.jms.subscribe.MessageReceiverStartupTrigger
starts a JMS listener to listen to any incoming replication requests.
RESTXQ
The RESTXQ implementation in eXist uses the trigger org.exist.exten
sions.exquery.restxq.impl.RestXqStartupTrigger to load its resource func‐
tion registry from the file $EXIST_HOME/webapp/WEB-INF/data/
restxq.registry . This is done so that the RESTXQ implementation can reregister
those resource functions that were previously registered before eXist was restar‐
ted. This ensures that resource functions remain available across database
restarts. For further details, see “Configuring RESTXQ” on page 216 .
Note that startup triggers are executed synchronously, and thus their executing will
block the database startup. Depending on your use of eXist, you might want to avoid
delaying the database startup any more than necessary. Startup triggers are effectively
executed in protected mode, as there is only a single database broker available and it
is provided to your startup trigger; hence, no other transactions will be taking place
against the database while the triggers are executing. Just as with system tasks (see
“Java system task job” on page 444 ), you need not worry about locking collections or
resources.
When creating your own startup trigger, you must implement the execute method
defined in org.exist.storage.StartupTrigger :
/**
* Synchronously execute a task at database startup before the database
* is made available to connections.
*
* Remember, your code within the execute function will block the database
* startup until it completes!
*
* Any RuntimeExceptions thrown will be ignored and database startup
* will continue. Database startup cannot be aborted by this trigger!
*
* Note: If you want an asynchronous trigger, you could use a future in your
* implementation to start a new thread; however, you cannot access the
* sysBroker from that thread as it may have been returned to the broker
* pool. Instead, if you need a broker, you may be able to do something
* clever by checking the database status and then acquiring a new broker
* from the broker pool. If you wish to work with the broker pool you must