Markus,
Can you post the EM acquisition for SB2. Is it injected or
application managed?
--Gordon
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.
>
> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>