Markus KARG wrote:
> Gordon,
>> This opens some other questions... You can not call em.refresh() on a
>> detached object (results in an exception) so how is this managed
>> entity getting into the second SB and why is there an existing
>> Persistence Context in the second SB if you are using the default
>> (TRANSACTION) Persistence Context type and there is not a transaction
>> spanning the 2 SB calls?
>> How is this second SB performing the 'lookup' ?
> The SBs are not related. As I said, SB1 send JMS, JMS triggers MDB.
> SB2 is triggered manually by the user. SB1 and SB2 are not related.
>
> The entity is kept by SB2 (which is a stateful SB) by just keeping it
> as a member variable. In the constructor, SB2 does
> em.find(Entity.class, PK) to find it, and then keeps it. When the
> client is calling SB2's business method, em.refresh(entity) is
> performed. The object does not get detached, obviously. To be able to
> do the em.find(PK) in the constructor, the client provides the PK.
If SB2 is stateful SB then it explains the behavior. The default type of
PersitenceContext for stateful bean is Extended. Hence find (correctly)
gives you the "stale" instance and refresh solves the issue.
-Mitesh
>
> So, the entity itself is not moved around, just it's PK.
>> I can not tell you why the refresh is needed. TopLink's cache will
>> be updated with the changes from the MDB transaction and subsequent
>> Persistence Contexts will see this update. That is why I was asking
>> the questions about the transactions and the types of Persistence
>> Contexts in the Session Beans. Based on your symptoms it points to
>> the second SB using a pre-MDB Persistence Context that contains an
>> old version of the Parent object. Persistence Contexts are an
>> intentionally isolated object space and will not have the changes
>> from another Persistence Context or transaction.
> So that means that you think there is a bug in TopLink? I mean, either
> my code is right or it is not. So either there is a bug in TopLink, or
> there is not. Since I am just a JPA novice, how should I know whether
> to report it as a bug or not? I need you to be the judge. :-)
>
> Thanks
> Markus
>> --Gordon
>>
>> Markus KARG wrote:
>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>