Mitesh,
>>>>> 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.
>> So that means that SLSB, SFSB and MDB have different defaults for
>> their PersistenceContext behaviour. In the JPA spec I found: "If the
>> type element is not specified, a transaction-scoped persistence
>> context is used.". So there must be another chapter of the spec that
>> contains the part with the stateful default. Can you point me to
>> where I can find that? :-)
> I was wrong. Sorry for the confusion.
Nobody's perfect, at least myself. ;-)
> I think answer to Gordon's questions above should help move forward.
As I already answered (maybe you missed that part of the discussion): I
do not do an em.find a second time. The em.find is done only in the
constructor of the SFSB. In the business interface of the SFSB the
entity reference stored in the constructor is just getting used.
Regards
Markus
>
> -Mitesh
>
>>
>> -Markus
>>
>>>
>>> -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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
http://www.xing.com/go/invita/58469