On 09/10/2011 02:47 AM, Marina Vatkina wrote:
> Carlo de Wolf wrote:
>> I'm in favor, but we previously discarded the idea because of
>> backwards compatibility.
>
> Yes. This is my concern as well. Does anybody has a suggestion on how
> to accomplish it without breaking the 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.)
>
> Can you please elaborate a bit more?
Given three scenarios:
1. @TX(Required) BeanA { @EJB myStateless; }
2. @TX(Never) BeanB { @EJB myStateless; }
3. BeanC { @EJB myStateless; @PostConstruct { ctx.setRollbackOnly(); }}
If the transaction is propagated as is we would get three different
instances in the pool (assuming pool semantics).
1. I saw a transaction and participated
2a. I did not see a transaction
2b. I did not see a transaction and started my own.
3. I saw a transaction, participated and was rolled back
While all three instances should be confronted with the same conditions.
Most likely we would have to treat the transaction attribute of a
lifecycle callback similar to transaction attribute on Singleton or MDB.
Thus Required is interpreted as RequiresNew, Mandatory is illegal etc.
This in term might break existing apps.
I tend to favor to specify the transactional context however, but that's
just a personal opinion.
Carlo
>
> thanks,
> -marina
>>
>> 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
>>>>>
>>>>>
>>>>>
>>>
>>