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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>