I was thinking about SFSBs only - SLSB/MDBs do not hold the state, so
what (meaningful) can they do in those callbacks that would require a
transaction?
thanks,
-marina
Carlo de Wolf wrote:
> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>>
>