Not all of us are sleeping but rather, watching with interest -its been
a while since you guys ran through this type of exercise.
I don't know about the others but -do keep going. This list has been
dead lately maybe this will liven things up a bit.
----- Original Message -----
From: Cedric Beust <[EMAIL PROTECTED]>
Date: Tuesday, May 22, 2001 6:33 pm
Subject: Re: CMP relationships in EJB2.0
> This is turning into a really nitpicking exercise, but hey,
> everyone else
> seems to be sleeping on the list, and as long as it improves my
> knowledge of
> the specification, I'm game.
>
> > From: Evan Ireland [mailto:[EMAIL PROTECTED]]
>
> > No, it just means Jonathan didn't look hard enough. I found it
> though.> Last sentence in section 9.5.3.
> >
> > "After an entity object has been removed, subsequent attempts
> > to access the entity object by a remote client result in the
> > java.rmi.NoSuchObjectException."
>
> I guess it boils down to defining precisely "removing an Entity
> object". Is
> this synonym of "calling ejbRemove()" or "deleting the database
> row that it
> represents"?
>
> > Also the last sentence in section 9.7.1.
> >
> > "All references to an entity object that does not exist are
> invalid. All
> > attempted invocations on an entity object that does not exist
> result in
> > an java.rmi.NoSuchObjectException being thrown."
>
> Same remark: what is an "entity object that doesn't exist"? An
> Entityobject whose row has been deleted or an object on which
> ejbRemove() has been
> called?
>
> > Also in 10.3.4.1 (second bullet point)
>
> This one doesn't count IMO, since it clearly says that
> NoSuchObjectExceptionshould be thrown in case an *accessor* is
> called on a deleted object.
> That's not what we are discussing.
>
> When we reach into the specification at such a subatomic
> (hyperstring ;-))
> level, common sense should prevail. What you and Jonathan are
> proposingwould allow an early catch of a possible error, but it
> would also make the
> example I described impossible to implement (an external process
> replacing a
> row with another one with the same PK but different values).
>
> I'll let the readers decide for themselves. I don't know about
> you guys,
> but this discussion has made me thirsty.
>
> --
> 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".
