Gordon,
> 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.
As I have seen the code is not exactly as I thought. The stateful
session bean that does the lookup is not keeping the PK but the actual
entity. So there is no em.find() actually. I added a em.refresh(entity)
now before the call of the lookup. Guess what, that is working.
But unfortunately, I have not understood why that refresh is needed. I
thought that as soon as I set both sides of the relationship that will
update the object, but it seems it does not. Can you give me a very
brief description why that refresh() is needed? I mean, isn't TopLink's
cache "seeing" that another TX changed the number of children in the
relationship?
Thanks a lot!
Markus
> --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