The intent of the specification, as described in sections 10.3.6
through 10.3.8 is that the referential integrity of the relationships
is maintained by the container. When the Bean Provider updates one
side of a bidirectional relationship, the update is immediately visible
from the other side. It is the responsibility of the container to ensure
this.
In Richard's examples, both the first and second case must result in
TRUE. The collection object is not cloned, so the effect of the
update is seen through the various references to it.
When an object is added to a collection-valued cmr-field, this update
must be "immediately" visible within the same transaction context. It
would be incorrect to implement this in such a way that the update was
not visible to other objects in the same tx context (e.g., by deferring
the update to the tx commit).
The warning with regard to Iterators stems from the restriction in the
java.util.Iterator API that the behavior of an iterator is unspecified
if the underlying collection is modified while the iteration is in
progress other than by calling the Iterator remove() method.
regards,
Linda
Linda DeMichiel
EJB 2.0 Specification Lead
Java 2 Platform, Enterprise Edition
Java Software, Sun Microsystems
[EMAIL PROTECTED]
>X-Accept-Language: en
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Date: Tue, 15 May 2001 05:45:23 -0500
>From: Richard Monson-Haefel <[EMAIL PROTECTED]>
>Subject: Re: EJB 2.0: Bi-Directional Relationships
>Comments: To: Alex Smith <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>
>Alex Smith wrote:
>
>> Richard Monson-Haefel <[EMAIL PROTECTED]> wrote:
>>
>> >Bi-directional relationships create some interesting situations, when
>> >concerned with establishing relationships between two participants. The
>> >following scenario illustrates a problem that I would like vendors to
>> >comment on, if they are up for the challenge.
>> >
>> >Assume that SalesRep has a one-to-many bidirectional relationship with
>> >Customer.
>> >
>> >------------------
>> >
>> >SalesRep rep = SalesRepHome.findByPrimaryKey(somekey);
>> >
>> >Customer cust = CustomerHome.create( );
>> >
>> >cust.setSalesRep( rep);
>> >
>> >Colleciton colleciton = rep.getCustomers( );
>> >
>> >if(collection.contains( cust ))
>> > flag = true;
>> >else
>> > flag = false;
>> >
>> >-------------------
>> >
>> >What is the value of flag? I suspect it should be true in this
>> >scenario.
>>
>> The flag will be true only if the implementation of setSalesRep() does
>> rep.add(this) where this is the Customer EJBObject. Alternatively if the
>> sales rep => customer relationship has been established prior to this chain
>> of events the flag will be true.
>>
>> Are you perchance after a mechanism where either side (rep -> customer,
>> customer -> rep) of the relationship is automatically updated?
>> If so, then I don't think containers do that: you have to "manually" update
>> both sides. The convention is to do it from the one side (sales rep) in the
>> many direction (collection of customers or in the session bean that wraps
>> them.
>
>This is interesting. You believe that the bean developer must manually set the
>relationships and I believe that they must be set automatically by the
>container. Why would the specification define these relationships in the
>abstract persistence schema if you have to set them up "manually"? It doesn't
>make sense. The container should automatically apply the other end of the
>relationship when its bi-directional. For example, setting the SalesRep on
>Customer should automatically add the Customer to the SalesRep's customers
>relationship field. How do others interpret this?
>
>--
>Richard Monson-Haefel
>Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
>Co-Author of Java Message Service (O'Reilly 2000)
>http://www.jMiddleware.com
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
