Binary Stores
Usage
Binary Stores contain run time data, e.g. watch point files, written during workflow runtime.
Data are written into binary store folders during workflow run time, e.g. through scheduler, listener call, test mode execution.
Data are cleared in binary store folders at the end of the workflow execution and are copied into the <inubit-installdir>/inubit/server/ibis_root/ibis_data/binarystores/testwatch
folder for the purpose of viewing data in a watch point.
If data are not cleared completely, a node crash or node shutdown during the process execution can be the reason.
Kind of Stored Data
There are two kinds of data written into binary stores:
-
Main
-
It contains variables/message data other than Workflow Connector, Multiplexer, and Wait modules.
-
The entry in the
is_transaction.xml
file contains serialized transaction data. It basically represents a pointer to the currently executed workflow and module. -
When a node has crashed, the
is_transcation.xml
file is used to restart/resume the process on another node.
-
-
Other
-
The entry in the
is_wait_transactional.xml
contains serialized wait transaction data with parts of the workflow whose sets of modules after the split/split branches are still to be executed. -
Message/variables for a Multiplexer branch.
Incoming message and variables at a Multiplexer still possibly having to be merged with data from other multiplexer branches
-
Message/variables for a WAITING process (Wait module or Task Generator)
-
Message/variables for a process in state ERROR
-
Variables for Workflow Connector return (
vartmp
). The variables are saved before the Workflow Connector execution, so that they can be restored after the Workflow Connector has finished.They are possibly merged with variables returned by the invoked workflow.
-
Retry- and Suspend- related data, data for input/output message logging, data for Web Service correlation, etc.
-
The database user needs the CREATE SESSION right, the CREATE SEQUENCE right, all table rights, and all index rights. To avoid problems with special characters, you should activate UTF‑8 encoding for the databases. |
To prevent a node shut down caused by a short-term database disconnection, you can configure a so-called leaky bucket. Database disconnections are counted. If the number of disconnections has exceeded the defined maximum within a certain interval, the node is shut down. Otherwise, the counted number of disconnections is reduced by the percentage configured.
For this purpose, you can set the following parameters:
-
Using the command line interface (CLI):
-
Number of database disconnections that must not be exceeded within the
interval
specified, default value:25
-
Percentage of short-term database disconnections the number of which is removed after the
interval
has expired, default value:4%
-
Time interval in seconds used as a delimiter for the number of database disconnections that must not exceed the specified
threshold
, default value:3600
seconds
-
-
Using the files
ibis.xml
(cache database) orlogsDBConfig.xml
(logging database):-
Number of retries and delay between the retries for database queries.
Refer to
-