Note that this should also imply allowances for usage of setRollbackOnly
and getRollbackOnly.
(EJB 3.1 FR 4.6.1, 4.7.2)
I still say that a SLSB lifecycle callback should have an isolated tx
context.
Carlo
On 09/15/2011 04:31 AM, Pete Muir wrote:
> I think this sounds reasonable - make it possible to enable TX, but not by default for backwards compat.
>
> I think this has to cover at least 80% of use cases.
>
> On 12 Sep 2011, at 20:20, Marina Vatkina wrote:
>
>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>>>