Don't give up! :-)
It seems you are right since em.refresh() is working. Please see my
other mail.
Thanks
Markus
Gordon Yorke schrieb:
> I have no more suggestions. You will have to file an EclipseLink bug
> and attach a reproduction.
> --Gordon
>
> Markus KARG wrote:
>> Gordon,
>>> What is the Persistence Context type of the Stateful Session Bean?
>>> Default, TRANSACTION or EXTENDED?
>> Default
>>> If the Application Client is not starting a user transaction for
>>> this series of calls then your assessment of the transactions would
>>> be correct and the problem is not the transactions.
>> The Application Client IS NOT starting a user transaction.
>>> Is the Session Bean and the MDB using the same Persistence Unit?
>> Yes, since both are part of the same EJB-JAR and there is only one
>> persistence.xml file with only one Persistence Unit definition in
>> that jar.
>>
>> Thanks
>> Markus
>>> --Gordon
>>>
>>> Markus KARG wrote:
>>>> Gordon,
>>>>
>>>> the situation is not that complex at all since there is no TX to
>>>> propagate:
>>>>
>>>> Currently it is like this:
>>>>
>>>> ACC driven client calls SB.
>>>> Since there is no TX, TX is started.
>>>> The SB creates an object, then send JMS message to topic.
>>>> End of SB method. --> TX will end, since it was started
>>>> automatically (not propagated).
>>>>
>>>> MDB reacts to JMS.
>>>> Since it is an MDB, a new TX is started.
>>>> MDB adds object.
>>>> End of MDB method. --> TX will end, since it was started
>>>> automatically (typical to MDB).
>>>>
>>>> ACC driven client calls the same SB session again (not closed
>>>> meanwhile).
>>>> Since there is no TX, TX is started // you think it is the same TX,
>>>> it will end after the first ACC call ends. Doesn't it?
>>>> SB's JPA lookup doesn't see the object.
>>>> But it should, since this is TX 3, not TX 1.
>>>>
>>>> Isn't that correct?
>>>>
>>>> So why in my actual above scenario you think there is a propagation
>>>> problem?
>>>>
>>>> Thanks
>>>> Markus
>>>>
>>>> Gordon Yorke schrieb:
>>>>> The default for Session Beans is transaction required which means
>>>>> if there is an existing transaction ( from a previous Session
>>>>> Bean call or a user transaction) it will be propagated along with
>>>>> the Persistence Context to the called Session Bean method. If
>>>>> there is no existing transaction then a new one will be begun.
>>>>> With Message Driven Beans because of the asynchronous nature of
>>>>> these beans the transaction will not be propagated through the
>>>>> message to the MDB. This means that the updates that are being
>>>>> performed in the MDB are in a separate transaction from the
>>>>> Session Beans and will never be joined and will not share the same
>>>>> Persistence Context.
>>>>>
>>>>> So say you had a Session Bean method that sent a message to a MDB
>>>>> then called to another Session Bean to verify the write of the
>>>>> MDB. With Persistence Context propagation the Session Beans would
>>>>> share the same Persistence Context and if the Persistence Context
>>>>> had a version of the Parent object loaded before the MDB performed
>>>>> its changes then the state integrity requirements of the
>>>>> Persistence Context would mean that the second Session Bean can
>>>>> not see the changes performed by the MDB.
>>>>>
>>>>> 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.
>>>>> --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