What is the Persistence Context type of the Stateful Session Bean?
Default, TRANSACTION or EXTENDED?
If the Application Client is not starting a user transaction for this
series of calls then your assessment of the transactions would be
correct and the problem is not the transactions.
Is the Session Bean and the MDB using the same Persistence Unit?
--Gordon
Markus KARG wrote:
> Gordon,
>
> the situation is not that complex at all since there is no TX to
> propagate:
>
> Currently it is like this:
>
> ACC driven client calls SB.
> Since there is no TX, TX is started.
> The SB creates an object, then send JMS message to topic.
> End of SB method. --> TX will end, since it was started automatically
> (not propagated).
>
> MDB reacts to JMS.
> Since it is an MDB, a new TX is started.
> MDB adds object.
> End of MDB method. --> TX will end, since it was started automatically
> (typical to MDB).
>
> ACC driven client calls the same SB session again (not closed meanwhile).
> Since there is no TX, TX is started // you think it is the same TX, it
> will end after the first ACC call ends. Doesn't it?
> SB's JPA lookup doesn't see the object.
> But it should, since this is TX 3, not TX 1.
>
> Isn't that correct?
>
> So why in my actual above scenario you think there is a propagation
> problem?
>
> Thanks
> Markus
>
> Gordon Yorke schrieb:
>> The default for Session Beans is transaction required which means if
>> there is an existing transaction ( from a previous Session Bean call
>> or a user transaction) it will be propagated along with the
>> Persistence Context to the called Session Bean method. If there is
>> no existing transaction then a new one will be begun.
>> With Message Driven Beans because of the asynchronous nature of these
>> beans the transaction will not be propagated through the message to
>> the MDB. This means that the updates that are being performed in the
>> MDB are in a separate transaction from the Session Beans and will
>> never be joined and will not share the same Persistence Context.
>>
>> So say you had a Session Bean method that sent a message to a MDB
>> then called to another Session Bean to verify the write of the MDB.
>> With Persistence Context propagation the Session Beans would share
>> the same Persistence Context and if the Persistence Context had a
>> version of the Parent object loaded before the MDB performed its
>> changes then the state integrity requirements of the Persistence
>> Context would mean that the second Session Bean can not see the
>> changes performed by the MDB.
>>
>> Try clearing the Persistence Context in the Session Bean that is
>> attempting to see the changes from the MDB before performing the find
>> and the changes should then be loaded into the Persistence Context.
>> --Gordon
>>
>> Markus KARG wrote:
>>> I have not changed the transactional settings, so the defaults apply
>>> in both, the SB and the EB.
>>> AFAIK the default is that a TX is automatically started and finished
>>> around the invocation, isn't it?
>>>
>>> Gordon Yorke schrieb:
>>>> Hello Markus
>>>> What are the transactional boundaries for the listening SB?
>>>> Is the em you are accessing in the listener in a transaction and
>>>> reading transactional data?
>>>> --Gordon
>>>>
>>>> Markus KARG wrote:
>>>>> I forgot to mention: Exactly the same code executed from within a
>>>>> session bean results in the new child beeing listed correctly.
>>>>>
>>>>> So what difference is between a MDB and a SB?
>>>>>
>>>>> Thanks! :-)
>>>>> Markus
>>>>>
>>>>> Markus Karg schrieb:
>>>>>> I have a strange problem and need your kind help. :-)
>>>>>>
>>>>>>
>>>>>> In GlassFishv2ur2, I am running a session bean that does:
>>>>>>
>>>>>> parent = em.find(ParentEntity.class, 1000).getSingleResult();
>>>>>> parent.getChildren();
>>>>>>
>>>>>> which lists the content of a OneToMany relationship.
>>>>>>
>>>>>> Now a message driven bean does:
>>>>>>
>>>>>> parent = em.find(ParentEntity.class, 1000).getSingleResult();
>>>>>> child = new ChildEntity(parent); // Implicitly sets "One"-Side
>>>>>> parent.getChildren().add(child); // Explicitly sets "Many"-Side
>>>>>> em.persist(child);
>>>>>>
>>>>>> When I go to the DBMS, I can see the row of the new child
>>>>>> including all fields. The child is correctly linked with the parent.
>>>>>>
>>>>>> But when running the listing again:
>>>>>>
>>>>>> parent = em.find(ParentEntity.class, 1000).getSingleResult();
>>>>>> parent.getChildren();
>>>>>>
>>>>>> Then still I do not see the new child. To make it appear, I must
>>>>>> undeploy and deploy. That is very weird, since it can be seen in
>>>>>> the database table, and I have set both sides of the relationship
>>>>>> as you can see in the code snippet.
>>>>>>
>>>>>> Looks like a cache problem, but I just do not understand how to
>>>>>> solve it.
>>>>>>
>>>>>> Has anybody an idea what the cause is and how to get rid of it?
>>>>>>
>>>>>> Thanks a lot! :-)
>>>>>> Markus
>>>>>>
>>>>>> QUIPSY QUALITY GmbH & Co. KG
>>>>>> Ein Unternehmen der MES-Gruppe
>>>>>> Stuttgarter Strasse 23
>>>>>> D-75179 Pforzheim
>>>>>> Tel: 07231-9189-52
>>>>>> Fax: 07231-9189-59
>>>>>> www.quipsy.de
>>>>>> karg_at_quipsy.de
>>>>>> Registergericht Mannheim HRA 701214
>>>>>> Geschäftsführer: Nils Schroeder
>>>>>>
>>>>>> Diese E-Mail enthält persönliche, vertrauliche und vor Weitergabe
>>>>>> geschützte Informationen und ist ausschließlich für den
>>>>>> vorgesehenen o.g. Empfänger (Adressaten) bestimmt. Falls Sie
>>>>>> diese E-Mail versehentlich erhalten haben und nicht der
>>>>>> vorgesehene Empfänger sind, bitten wir Sie, die E-Mail und deren
>>>>>> Anhänge nicht aufzubewahren, nicht zu vervielfältigen, nicht zu
>>>>>> nutzen und nicht weiterzugeben. Bitte informieren Sie uns als
>>>>>> Absender über diesen Zustellungsfehler und löschen Sie die E-Mail.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>