Thanks everybody who chimed in (and resending Adam's email that didn't
make it to the EG alias)
Load can be non-transactional (and it will preserve isolation levels),
though I understand that it'd be strange to allow transactions on
PreDestroy but on on PostConstruct. So this is not an issue. The real
issue is the backward compatibility. We can't just break something that
was the same way for a very long time.
But we can allow to specify transactional attribute on the callback
methods of a SFSB directly if this solves the problem.
Q: Are there cases when it is not possible to do via annotations or DD?
thanks,
-marina
Adam Bien wrote:
> Hi Marina,
>
> if you are accessing a EntityManager you will need to start a transaction. Usually you also would like to access the DB in a TX to have consistent reads and rely on defined isolation level settings.
> @PreDestroy is even more crucial. It could be used to flush the cache to a DB.
>
> I use sometimes Singletons in single node clusters for deferred writes.
>
> thanks!,
>
> adam
>
>
>
> On 10.09.2011, at 02:45, Marina Vatkina wrote:
>
>
>> Adam,
>>
>> Can you describe the issue in more details? When will pre-fetching data in Singleton's PostConstuct would need to be transactional?
>>
>> thanks,
>> -marina
>>
>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
>