Gordon,
> Markus,
> Can you post the EM acquisition for SB2. Is it injected or
> application managed?
> --Gordon
It is injected. My application doesn't care about anything, neither
persistence context nor transactions, but solely uses that nice magics
behind Java EE 5 everywhere. :-)
What do you mean with "posting the acquisition" (my English is not so
well)? Do you mean the source code? It's like this:
@PersistenceContext
private EntityManager em;
Thanks
Markus
>
> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
http://www.xing.com/go/invita/58469