Unfortunately I had been busy with teaching GlassFish all the day... I
will try ASAP.
Thanks
Markus
Gordon Yorke schrieb:
> Yes that is what I meant. Have you been able to try the em.contains()
> method as proposed by Marina?
> --Gordon
>
> Markus KARG wrote:
>> 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