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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>