Yes, if something is identified as broken it must be fixed.
This needs to same exemption clauses as the security context.
getRollbackOnly & setRollbackOnly also become available in lifecycle
callbacks.
The thing that we have to define properly is that lifecycle callbacks
initiate a new transaction if EJB 3 views are used. (This is turning
ugly fast.)
Or we keep the old behavior of unspecified transaction context.
Back to the drawing board...
Carlo
On 12/06/2011 12:35 AM, Marina Vatkina wrote:
> Aren't we trying to resolve all discrepancies in the spec?
>
> thanks,
> -marina
>
> reza_rahman_at_lycos.com wrote:
>> Given the very small number of people that use create() in EJB 3.0+,
>> I don't think this matters much either way.
>>
>> Dec 2, 2011 04:45:21 PM, marina.vatkina_at_oracle.com
>> <mailto:marina.vatkina_at_oracle.com> wrote:
>>
>> Guys,
>>
>> We have a problem...
>>
>> The spec (see the 3.2 core doc) has in most cases the statement
>> like in
>>
>> ========
>> 4.6.1Operations Allowed in the Methods of a Stateful Session Bean
>> Class
>> (1st bullet under table 1)
>> "The PostConstruct, PreDestroy, PrePassivate, PostActivate, Init,
>> and/or
>> ejbCreate, ejbRemove, ejbPassivate, and ejbActivate methods of a
>> session bean with container-managed transaction demarcation
>> execute with
>> an unspecified transaction context."
>> ========
>>
>> But there is also this text:
>>
>> ========
>> 16.4.5.2Stateful Session Beans
>> The invocation of the home create() method causes construction
>> of the bean instance, invocation of the PostConstruct lifecycle
>> callbacks, if any, and invocation of the matching Initmethod, and
>> returns the corresponding local component interface or remote
>> component
>> interface of the bean. The invocation of these methods occurs in the
>> same transaction and security context as the client’s call to the
>> create
>> method.
>> ========
>>
>> Should I add everywhere when I change the text about the unspecified
>> transaction context for SFSBs "unless PostConstruct lifecycle
>> callback
>> method is executed as a result of invocation of the home
>> create() method"?
>>
>> If yes, should I add an opposite note in the 16.4.5.2?
>>
>> If not, please advise...
>>
>> thanks,
>> -marina
>>
>> Jean-Louis MONTEIRO wrote:
>> > Well, that's definitely a popular request.
>> >
>> > If we wanna support transactions, REQUIRES_NEW is the only relevant
>> > attribute to use in my opinion.
>> > I guess from the discussion that we want to support transactions in
>> > SFSB and Singleton, but not yet for SLSB and MDB. Right?
>> >
>> > Jean-Louis
>> >
>> >
>> >
>> >
>> > 2011/12/1 Reza Rahman <reza_rahman_at_lycos.com
>> <mailto:reza_rahman_at_lycos.com>
>> > <mailto:reza_rahman_at_lycos.com>>
>> >
>> > I think this is the right change to make. In case of roll-back,
>> > the instance should become unusable. In this case
>> > REQUIRES==REQUIRES_NEW
>> >
>> >
>> > On 11/30/2011 8:54 PM, Marina Vatkina wrote:
>> >
>> > Experts,
>> >
>> > Looking at the long thread on this subject (XXX Transactional
>> > execution of a PostConstuct or PreDestroy method of a
>> > singleton session bean), I'm confused on the outcome of the
>> > discussion...
>> >
>> > Did we reach an agreement to allow transactional support for
>> > Pre/Post lifecycle callback methods of a SFSB (i.e. SLSB and
>> > MDB are not changed in this release)?
>> >
>> > If yes, did we agree that Required would mean RequiresNew in
>> > the transactional attributes (i.e. their execution is never a
>> > part of the client's transaction)?
>> >
>> > What would happen with a SFSB instance if transaction is
>> > rolled back during execution of the lifecycle callback?
>> >
>> > thanks,
>> > -marina
>> >
>> >
>> >
>> >
>> >
>> >
>> > -----
>> > No virus found in this message.
>> > Checked by AVG - www.avg.com <http://www.avg.com>
>> <http://www.avg.com>
>> > Version: 2012.0.1873 / Virus Database: 2102/4649 - Release
>> > Date: 11/30/11
>> >
>> >
>> >
>> >
>>