Gordon,
> What is the Persistence Context type of the Stateful Session Bean?
> Default, TRANSACTION or EXTENDED?
Default
> 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.
The Application Client IS NOT starting a user transaction.
> Is the Session Bean and the MDB using the same Persistence Unit?
Yes, since both are part of the same EJB-JAR and there is only one
persistence.xml file with only one Persistence Unit definition in that jar.
Thanks
Markus
> --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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
http://www.xing.com/go/invita/58469