Cloud CM-IPMP Průvodce řešením problémů Strana 115

  • Stažení
  • Přidat do mých příruček
  • Tisk
  • Strana
    / 201
  • Tabulka s obsahem
  • KNIHY
  • Hodnocené. / 5. Na základě hodnocení zákazníků
Zobrazit stránku 114
a deadlock is detected during lock acquisition.
18.2.3 Multiple Transactions
Multiple MemDB instances can be used in a single transaction, as MemDB supports a two-phase commit protocol. A common
scenario exists in the default Rhino SLEE configuration where an SBB receives an event and queries a Profile. In this example
the SBB is stored in one MemDB, and the Profile is stored in another.
18.3 Application Configuration
18.3.1 Replication
The default configuration of Rhino has two MemDBs. The first MemDB uses Synchronous Memory-to-Memory replication
and is used by SBBs, and Activity Context attributes. The second MemDB uses Synchronous Memory-to-Memory replication
with Asynchronous SQL replication and is used by Profiles.
18.3.2 Concurrency Control
As seen in Section 18.2 there are several possible combinations for configuring concurrency control within MemDB. SBBs are
able to be configured to use different concurrency control techniques.
The default concurrency configuration for SBB entities uses an entity-tree lock, and sets every SBB to optimistic. Before any
transaction delivers an event to an SBB in the SBB entity tree, it acquires the entity-tree lock. This model forces serial access to
the SBB entity tree, which means that deadlocks within an entity-tree are not possible. It also has a fixed lock acquisition cost
per event delivery.
Different SBB entity-trees are able to run concurrently as there is one lock per tree.
A concurrency configuration other than the default can be specified using Rhino’s extension deployment descriptors which are
discussed in Section 18.5. If a developer configures concurrency options other than the default it is expected that the developer
understands when various code paths in the SBB entity tree execute and has understood Rhino’s concurrency controls.
Profiles use optimistic concurrency control, and their concurrency control is not configurable. Profiles are read-only from SBBs
and therefore concurrency control conflicts are unlikely.
18.4 Multiple Resource Managers
Rhino SLEE supports the use of multiple Resource Managers the same transaction. For example consider the case that an SBB
is deployed that has its state in MemDB, and executes an SQL statement against a third party database. The third party database
and MemDB are now participants in the same transaction.
External Resource Managers are treated as though they do not support two-phase commit. In order to allow this (common) case
to proceed, Rhino uses the well-known Last Resource Commit optimisation to manage the transaction across the two-phase
Resource (MemDB) and the external Resource Manager. For more information on this approach please see Section D.4.3 in
Appendix D.
This means that the external database will be told to commit a transaction only after the successful preparation of all two-phase
resources. If the third party database fails to commit the transaction, it will rollback MemDB. If the third party database commit
succeeds the main working memory will commit.
18.5 Extension Deployment Descriptors
SBB developers and SLEE administrators can configure the deployment of SBBs in addition to JAIN SLEE 1.0 specification
by supplying an Open Cloud Rhino SLEE deployment descriptor in the SBB deployable unit. This extra deployment descriptor
is called an extension deployment descriptor.
Open Cloud Rhino 1.4.3 Administration Manual v1.1 106
Zobrazit stránku 114
1 2 ... 110 111 112 113 114 115 116 117 118 119 120 ... 200 201

Komentáře k této Příručce

Žádné komentáře