Carlo,
EM/EMF do not need to be created inside a transaction, more than that,
it'll just take longer to do so. Also, what can a SLSB do transactional
in PreDestroy? All transactions had already been finished, and the bean
instance is destroyed most probably because the pool is overflown.
Does anybody else has a business case for a SLSB to have those callbacks
transactional?
thanks,
-marina
Carlo de Wolf wrote:
> A SLSB instance is a stateful object. It is however without session.
>
> As an example a case I came across yesterday, a SLSB can be defined
> that connects to a PU.
> The instances hold state: the connection to the PU. While they service
> any client session-less.
>
> https://issues.jboss.org/browse/AS7-1848
>
> So I come back to my earlier statement:
> On 09/13/2011 11:16 AM, Carlo de Wolf wrote:
>> 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.
>>
>
> Carlo
>
> On 09/15/2011 10:03 PM, Marina Vatkina wrote:
>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>
>