Thanks again matterbury.
First of all the problem for me to solve is determining what I can do and what I can't do so as the EJB 3.0 spec states it. I mean, the spec tells nowhere that a @Remove marked cannot join a transaction! Indeed, it works: it joins the transaction, the problem is that it closes it.
CMT here is a requirement but I think it's not the point. The spec does not suggest that a SLB cannot be client of a SFB. Fine. Now: a SLB, by definition, does not maintain state: I can just use the storage in the scope of a business method. Hence, if I call a SFB, I _have_ to call a @Remove method from my business method! Otherwise, the SFB would remain hanging there until passivation and removal timeouts, which is a picture I'm determined to avoid.
Now what? If I'm using CMT, even the simplest picture would be a problem: the SLB starts the transaction and as far as I remove an SLB and call another bean that's what I have:
javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
I built a prototype and I can reproduce the problem. To try and solve it the first thing I thought about is running that method _outside_ the transaction. I marked the @Remove method as TransactionAttribute.NOT_SUPPORTED and now I have:
javax.ejb.EJBException: nested exception is: java.lang.IllegalStateException: Bean is associated with a different unfinished transaction
With this semantics, a SFB and a SLB cannot interact when the SLB starts the transaction: as soon as the first SFB gets removed, the transaction is gone. Now I wonder if the specs took into account such use case: I cannot found reasons why this use case would be prohibited.
[Message sent by forum member 'emcrisostomo' (enrico.m.crisostomo_at_gmail.com)]
http://forums.java.net/jive/thread.jspa?messageID=362728