I'm in favor, but we previously discarded the idea because of backwards
compatibility.
The one thing that requires immediate attention is how we'll deal with
SLSB lifecycle callbacks.
All instances should be initialized in similar vain or else we loose the
SL semantics.
(Picture somebody calling the SLSB with NEVER or rolling back a
transaction etc.)
Carlo
On 09/09/2011 01:27 PM, Adam Bien wrote:
> +1 for transactional callbacks. Had the issue in @Singletons, which prefetched the data from DB already.
> On 07.09.2011, at 14:40, Pete Muir wrote:
>
>> In general, it's very useful for a postconstruct/predestroy method to be able to be called within a transaction.
>>
>> For example, consider seeding data into a database (singleton with @Startup and an @PreDestroy), logging user access (http session scoped SFSB) and so on.
>>
>> On 7 Sep 2011, at 03:18, Marina Vatkina wrote:
>>
>>> Experts,
>>>
>>> Let's clarify transactional support for PostConstuct or PreDestroy methods.
>>>
>>> a) PostConstuct or PreDestroy methods of a singleton session bean can be executed in a transaction, while other bean types do not seem to allow this. Why would the singleton bean is different from any other bean?
>>>
>>> b) Why would the transactional attribute be specified differently for a singleton vs. other beans? See e.g. an XXX marker under section "8.3.7 Specification of the Transaction Attributes for a Bean’s Methods" in one of the bullets of the "Transaction attributes are specified for the following methods:" text:
>>>
>>> <...>
>>>
>>> For a singleton session bean, the transaction attributes are specified for the PostConstruct and PreDestroy lifecycle callback interceptor methods, if any. In order to specify the transaction attribute for a PostConstuct or PreDestroy method of a singleton session bean, the transaction attribute must be specified for the method(s) on the bean class, rather than for a superclass or PostConstruct or PreDestroy interceptor method."
>>>
>>> thanks,
>>> -marina
>>>
>>>
>>>
>