I see you're making us guys fit in transactions/exceptions. That's good.
I think the following happens to your beans:
1. SlsbOne throws a system exception.
2. Container logs the exception, marks the tx for rollback, discards SlsbOne and throws an EJBTransactionRolledbackException to the client, that is to SlsbTwo (compare core spec 14.3.1, table 14, second row).
3. SlsbTwo (re-)throws the EJBTransactionRolledbackException (= system exception).
4. Container logs the exception, rolls back the tx, discards SlsbTwo and throws an EJBException to the client, that is SlsbThree (compare core spec 14.3.1, table 14, fourth row).
5. In the catch-block of SlsbThree the EJBException is catched and the buisness method three() returns.
6. Since returning the business method of a stateless Session Bean with BMT without completing the transaction isn't allowed (see core spec 13.3.3), the container throws an EJBException, complaining "Stateless SessionBean method returned without completing transaction".
I disagree with enthuware about
5. The bean A instance will NOT be discarded.
being correct. I think both, bean A instance and bean B instance will
be discarded [due to core spec 14.3.1, table 14, fourth row resp. second row] - at least, if the system exception isn't catched in bean A. But if it is catched in bean A then the client won't get a javax.ejb.EJBException, so option "2" would be wrong.
I tried your sample with stateful beans with the following modifications in SlsbThree:
The output in (*) is "javax.ejb.NoSuchEJBException" indicating that the SlsbTwo instance was discarded, too.