defines the API for specifying entities to register and update.
Committing a transaction is actually a two-part process. The metadata is
stored in the openBIS application server's database; the data is kept on
the file system in a sharded directory structure beneath the data store
server's *store* directory. All modifications requested as part of a
transaction are committed atomically — they either all succeed or all
fail.
Several [Events](https://openbis.readthedocs.io/en/latest/software-developer-documentation/server-side-extensions/dss-dropboxes.html#events-registration-process-hooks) occur in the process of committing a transaction. By defining jython functions, it is possible to be notified
and intervene when an event occurs. Because the infrastructure reserves
the right to delay or retry actions if resources become unavailable, the
process function and event functions cannot use global variables to
communicate with each other. Instead, they should use the registration
context object to communicate. Anything stored in the registration
context must, however, be serializable by Java serialization.
Committing a transaction is actually a two-part process. The metadata is stored in the openBIS application server's database; the data is kept on the file system in a sharded directory structure beneath the data store server's *store* directory. All modifications requested as part of a transaction are committed atomically — they either all succeed or all fail.
Several [Events](./dss-dropboxes.html#events-registration-process-hooks) occur in the process of committing a transaction. By defining jython functions, it is possible to be notified and intervene when an event occurs. Because the infrastructure reserves the right to delay or retry actions if resources become unavailable, the process function and event functions cannot use global variables to communicate with each other. Instead, they should use the registration context object to communicate. Anything stored in the registration context must, however, be serializable by Java serialization.
Details
-------
### Dropbox Configuration
A jython dropbox is typically distributed as a [core
plugin](https://openbis.readthedocs.io/en/latest/software-developer-documentation/server-side-extensions/core-plugins.html) and configured in its
plugin.properties file. A dropbox configured to run a jython script,
which is kept in the same directory as plugin.properties. The
configuration requires a storage processor and the name of the script (a
full path is not necessary if the script is in the same directory as the
plugin.properties). Here is an example configuration for a dropbox that
uses the jython handler.
A jython dropbox is typically distributed as a [core plugin](./core-plugins.html) and configured in its plugin.properties file. A dropbox configured to run a jython script, which is kept in the same directory as plugin.properties. The configuration requires a storage processor and the name of the script (a full path is not necessary if the script is in the same directory as the plugin.properties). Here is an example configuration for a dropbox that uses the jython handler.
**plugin.properties**
...
...
@@ -677,10 +659,7 @@ failed only after, the whole retrying / recovery process will fail. It
means that it can take a long time before the .faulty\_paths file is
created, even when there is a simple dropbox error.
Therefor during development of a dropbox we recommend
using **[development mode](https://openbis.readthedocs.io/en/latest/software-developer-documentation/server-side-extensions/dss-dropboxes.html#development-mode)** , wich
basically sets all retry values to 0, thus disabling the auto-recovery
feature.
Therefor during development of a dropbox we recommend using **[development mode](./dss-dropboxes.html#development-mode)** , wich basically sets all retry values to 0, thus disabling the auto-recovery feature.
