SBB hierarchies and SLEE transactions (September 23, 2008)

In addition to my previous entry on the potential dangers of using re-entrant SBBs, here is another one describing interesting issue I have faced when working with SBB hierarchies. It involves SLEE transactions and underlying implementation mechanisms.

In my current project, the SBB hierarchy consists of three levels:

• root SBB, used as dispatcher for all incoming events;
• factory SBB, the only descendant of root SBB, used as, — well, right — a component factory;
• component SBBs, incorporating the main portion of business logic, a direct descendants of factory SBB.

Lowest-level SBBs are responsibe for communicating with Resource Adaptors, so the common pattern for execution is the sequence consisting of initial event handled by root SBB, cascade creation, and event exchange between RAs and lowest-level SBBs.

Sometimes business logic requires creation of another component — for this purpose every component SBB holds a reference to the factory’s local interface, allowing them to trigger creation of “brothers and sisters”. Note that every creation process is taking place in the scope of another (in comparison with the previous event processing cycle) event handler, and since event handlers are mandatory transaction methods, in the scope of another transaction.

Transactions mechanism surely requires some locking to be implemented. In the SLEE platform I am currently working with, locks are associated with the SBB entities and the locking mechanism is pessimistic (i.e. resources are locked immediately upon request). As transaction associated with initial event is propagating, we acquiring (among others) the locks of these SBBs, in this order: root SBB → factory SBB → component SBB. After the component finishes its work (which in the most cases relates to placing the request to RA and waiting for an event), the transaction commits. Those of events delivered to the component SBBs which require creation of new components will initiate a transaction with these locks: component SBB → factory SBB → another component SBB.

And sometimes underlying Resource Adaptor process the request so quickly, that the initial transaction have not finished its commit yet, and — you guessed — have not released the locks. Boom!, deadlock is detected (deadlocks of that sort is pretty easy to detect, and my SLEE implementation does it).

SBB hierarchy is going to be reshuffled now, and this would be a lesson for me to take even more care of the possible platform implementation tricks.