jsr345-experts@ejb-spec.java.net

[jsr345-experts] Re: XXX Transactional execution of a PostConstuct or PreDestroy method of a singleton session bean

From: Florent BENOIT <Florent.Benoit_at_ow2.org>
Date: Thu, 08 Sep 2011 09:10:33 +0200

+1

Florent
On 09/07/2011 05:23 PM, Reza Rahman wrote:
> +1. The consensus in EJB 3.1 was that singleton beans would need to
> initialize data in the life-cycle call-backs and hence do need to be
> transactional. In fact, I think it would be good if the life-cycles of
> the other beans were transactional as well :-).
>
> On 9/7/2011 8:55 AM, Carlo de Wolf wrote:
>> On 09/07/2011 04:18 AM, 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?
>>
>> Basically to prevent it from falling into the 8.6.5 escape clause.
>> Which explicitly specifies nothing. :-)
>>>
>>> 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
>>>
>>>
>>>
>> Can't recall why that last paragraph is how it is. I also can't think
>> of a reason.
>>
>> Carlo
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1392 / Virus Database: 1520/3881 - Release Date: 09/06/11
>>
>>
>