|
As persistent state is an integrated part of E2E Bridge, there is no requirement for additional components. The Components Wizard is used to create this diagram. For more details, refer to the E2E Builder User's Guide.
In the picture below, the completed component diagram of the Purchase Order example is displayed.
Figure: Components Diagram for Purchase Order Example
In the specification dialog of the E2E Composite, you can configure the persistent state engine.
Figure: Specification of E2E Composite PurchaseOrderExample
Attribute | Type | Description | Value | Description | ||
---|---|---|---|---|---|---|
Persistent State | ||||||
External State DB Alias | String |
| ||||
Storage Medium | String |
| memory | The persistent state data is kept in memory. On service shutdown, data is written to the file system. | ||
local (default) | The persistent state data is kept in a local SQLite database that is delivered with the E2E Bridge. | |||||
external | The persistent state data is kept in an external database that has to be defined as a service backend. Use External State DB Alias to specify the database. | |||||
volatile | The persistent state data is kept in memory. On service shutdown, data is lost. | |||||
Workers | Integer |
| ||||
Switch Over Enabled | Boolean |
| false (default) | fail over mechanism not enabled | ||
true | fail over mechanism enabled | |||||
Switch Over Retry Timeout | Integer |
| ||||
Internal State DB Synch | String |
| OFF (default) | SQLite continues without syncing as soon as it has handed data off to the operating system. If the xUML service crashes, the data will be safe, but the database might become corrupted if the operating system crashes or the computer loses power before that data has been written to the disk surface. Very fast. | ||
NORMAL | The SQLite database engine will still sync at the most critical moments, but less often than in FULL mode (see below). There is a very small (though non-zero) chance that a power failure at just the wrong time could corrupt the database in NORMAL mode. But in practice, you are more likely to suffer a catastrophic disk failure or some other unrecoverable hardware fault. Up to 50 times slower than OFF. | |||||
FULL | The SQLite database engine will ensure that all content is safely written to the disk surface prior to continuing. This ensures that an operating system crash or power failure will not corrupt the database. FULL synchronous is very safe, but it is also slower than NORMAL. FULL is the most commonly used synchronous setting. | |||||
EXTRA | Also synchronize the DB transaction journal after every commit. Equals FULL in E2E Bridge context. |
|
As persistent state is an integrated part of E2E Bridge, there is no requirement for additional components or deployments. The Deployment Wizard is used to create these diagrams. For more details, refer to the E2E Builder User Guide. In the picture below, the completed component diagram of the Purchase Order example is displayed. Figure: Components Diagram for Purchase Order Example The only difference to a regular diagram is in the artifact PurchaseOrderExample to the right. In the specification dialog of an artifact of stereotype <<E2EConfigurationDeployment>> there are two fields for configuring the persistent state engine. Figure: Specification of Artifact PurchaseOrderExample Workers defines the maximum number of parallel threads used to process pending events. The default setting is 5, which is used if none or 0 workers are configured. The implications of more or less workers are discussed in Performance Considerations of Persistent State.
Storage Medium defines where the persisted data and additional information like pending events and current states are kept. Valid options are memory, local or the name of a database instance. See section Data Storage for a discussion of the options. When using a database instance as storage medium, make sure to configure components and deployment of the SQL adapter as described in section SQL Adapter. |