This begs the next obvious question which is, was it the intent of the EJB
architects that EJB move towards and object database design, and away from a
relational database design. The spec makes it quite clear that entity
beans relate to any persistant store. That store could be anything at all,
not necessarily a relational database. However I think in most developers
minds they view the store as an RDBMS.
But there are inconsistancies in the EJB design which beg the question of
was this ever really designed to run over an RDBMS. Questions like the one
posed here on the immutability of a PK. As stated, the releational model
places no restrictions on updating of PK columns.
But we can see these inconsistancies in other places. For instance take
basic entity beans. The consistancy model makes a quite sweeping assumption
which is that the underlying data store is unchanging between load and store
operations. The spec does discuss the formation of diamond conditions due
to clustering etc, but never discusses the formation of logical diamonds due
to the underlying datastore being changed. Although there are solutions
(optimistic locking, other solutions we are pursuing etc) this still
presents a data corruption issue. So to prevent this, we should prevent
stove piped access to the data store. If you cant get to the underlying
data directly, no diamond can form. Now, if we prevent stove piped access
to the data store, I can see no reason for O:R mappings, as the only access
path to the data would be via the entities. If there is no O:R mapping then
we can indeed store the entity in an opaque fashion, again as no one can get
to the data except via the entities. Now if this is so, why use an RDBMS
anyways, why not use an object database? Or, does a well designed in-memory
entity bean implementation replace the OODBMS?
These basic questions still haunt the direction of EJB and unless managed
will lead to more issues like Jay originally posted.
Dave Wolf
Internet Applications Division
Sybase
----- Original Message -----
From: "Lawrence Marsh" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 05, 2001 8:10 AM
Subject: Re: EJB 1.1 and change of primary key values
> It seems to me that a primary key is immutable if and only if it serves as
> the object identity of the object whose state is represented by the row in
> the table to which the primary key points.
>
> So if your underlying data model supports these semantics then the primary
> key should indeed be immutable.
>
> The problem is that there is nothing in the relational world that forces
you
> to adopt those semantics in your data model which is why in the relational
> world you can change the primary key. Hence why the primary key cannot be
> immutable in EJB.
>
> What would be interesting would be a mechanism within EJB to allow the
bean
> provider to indicate these semantics in some way (for example throught the
> deployment descriptor) so that if a client did inadvertantly try to change
> the primary key the bean threw an exception.
>
> Cheers
>
> Lawrence
>
> > ----------
> > From: Jay Walters[SMTP:[EMAIL PROTECTED]]
> > Reply To: A mailing list for Enterprise JavaBeans development
> > Sent: 05 April 2001 13:30
> > To: [EMAIL PROTECTED]
> > Subject: Re: EJB 1.1 and change of primary key values
> >
> > Now in EJB 2.0 it would be much easier to implement immutable primary
keys
> > in the CMP environment because of the abstract persistence schema. The
> > implementation class could throw an exception on change of primary key
> > fields. Do you guys think this should be done, or still left open?
> > Personally I'd like some option to go either way.
> >
> > Cheers
> > Jay
> >
> > -----Original Message-----
> > From: Cedric Beust
> > To: [EMAIL PROTECTED]
> > Sent: 4/4/01 4:57 PM
> > Subject: Re: EJB 1.1 and change of primary key values
> >
> > > From: Dave Wolf
> >
> > > Its an interesting question whether the pk is semantically immutable.
> > I
> > > dont see the spec every lay this out as a requirement. Secondly, if
> > we're
> > > persisting to an RDBMS which 90% of people are, the RDBMS does
> > actually
> > > allow updates on the PK field. So this PK mutability can occur
> > actually
> > > outside the EJB and bring about the same issue. Since neither EJB nor
> > the
> > > RDBMS enforce the relational models view that nothing changes the PK
> > value
> > > (a natural key) then how can we assume it is immutable?
> >
> > Because it doesn't make sense otherwise? :-)
> >
> > For example, Hashtable doesn't specify that equals()/hashCode() need to
> > return the same value after the object has been stored in the table, but
> > the
> > behavior is unpredictable if they don't.
> >
> > Not hard to extend this consideration to PK's.
> >
> > Be nice to the container and the container will be nice to you :-)
> >
> > --
> > Cedric
> >
> > ========================================================================
> > ===
> > 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".
> >
>
>
> Visit us at http://www.clearstream.com
> Check out current job vacancies at
http://www.clearstream.com/public/english/e_vacs.htm
>
> IMPORTANT MESSAGE
>
> Internet communications are not secure and therefore Clearstream
International does not
> accept legal responsibility for the contents of this message.
>
> The information contained in this e-mail is confidential and may be
legally privileged. It is
> intended solely for the addressee. If you are not the intended recipient,
any disclosure,
> copying, distribution or any action taken or omitted to be taken in
reliance on it, is
> prohibited and may be unlawful. Any views expressed in this e-mail are
those of the
> individual sender, except where the sender specifically states them to be
the views of
> Clearstream International or of any of its affiliates or subsidiaries.
>
> END OF DISCLAIMER
>
>
===========================================================================
> 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".
