ESBExit

Critical Section

A BusinessWorks Critical Section serialises access to a shared resource. Camel has no direct analogue, and what you choose instead depends on whether the lock was ever really cluster-wide.

Caveat com.tibco.pe.core.CriticalSectionGroup

What it does in BusinessWorks

Wraps a set of activities so that only one job may execute them at a time. Scope is either Single Group (per engine) or a named Lock Object shared across the engines in a deployment. That distinction is the whole migration.

The Camel equivalent

Which form you land on depends entirely on the scope the original used, and the two are not interchangeable.

BusinessWorks 5group configuration
Group type   Critical Section
Scope        Lock Object    shared across engines
             Single Group   one engine at a time
Lock Object  a named shared resource
Apache CamelJava DSL
// Lock Object scope -> one active consumer in the cluster
from("master:StockLock:direct:reserveStock")
    .routeId("ReserveStock")
    .to("bean:stock?method=reserve");

// Single Group scope -> far simpler
from("direct:reserveStock")
    .synchronous(true)
    .to("bean:stock?method=reserve");

Where the semantics diverge

Three differences matter. The generator warns about the first and is silent on the other two.

Lock granularity. BusinessWorks locks for the duration of the group. camel-master elects a single active consumer for the lifetime of the route, a coarser guarantee. If the group was short and the route is long-lived, you have changed the concurrency profile of the whole service, not just that section.

Failure behaviour. A BusinessWorks lock is released when the engine dies. A distributed lock backed by Infinispan or a database releases on lease expiry, leaving a window in which nobody holds it, and a window in which two holders believe they do. Any migration of a Lock Object needs an idempotency key downstream; there is no configuration that removes this.

Ordering. BusinessWorks queues waiting jobs in arrival order. Camel promises no ordering across a cluster. Where the original design relied on FIFO, implicitly or otherwise, that ordering has to be reintroduced explicitly.

What the toolchain does

Less than this page might suggest, and it says so out loud. A Critical Section group is emitted as .transacted() together with a warning that this does not provide mutual exclusion. The generator does not choose a lock for you, does not write an idempotency key, and does not test ordering.

Reading the warning and deciding what replaces the lock is work that stays with you.

In the corpus this is a group rather than an activity, which is why it does not appear in the activity table on the homepage.

Related activities