Experts,
Working on the RI for transactional support of SFSB lifecycle callbacks
as it is described in the current spec, we had identified 2 issues:
1. It breaks backward compatibility for the existing SFSBs (and though I
know that some of you doesn't think it's very important, we can't do this).
I did find an email thread where we agreed that the lifecycle callbacks
will need to be opted-in to be transactional (sorry I missed it when I
was updating the EDR).
This means that the current occurrences of the text "determined by the
bean’s transaction management type and any applicable transaction
attribute" will be replaced with "determined by the lifecycle callback
method's transaction attribute".
For the opt-in support I'll add to the spec that only 2 transaction
attributes values are allowed: REQUIRES_NEW and NOT_SUPPORTED (though
the latter doesn't add much, so if you feel that only the former should
be allowed, let me know). REQUIRED will not be allowed because a) the
value needs to be specified anyway, and as such it should be exact, and
b) by default lifecycle callbacks will continue to be executed in an
unspecified transaction context (opposite to the Singletons which being
new, could have a different default).
2. We didn't address SessionSynchronization callbacks in SFSBs with
regards to the transactions in lifecycle callbacks.
In my opinion, the SessionSynchronization callbacks should not be called
because a) the instance is either not fully constructed or being
destroyed, and b) there is no long-running transaction that the bean
needs to react to.
Let me know if you think otherwise.
thanks,
-marina