I have no more suggestions. You will have to file an EclipseLink bug
and attach a reproduction.
--Gordon
Markus KARG wrote:
> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>