Chip Wilson wrote:
>
> "Willecke, Dirk" wrote:
> >
> > I can't find something in the spec about it. If a container
> simply executes
> > the finder method, this would look up the database and person No 100
> > wouldn't
> > be found. By the way: a findByName("Simpson") would find
> Mr. Smith!!!
>
> It would find Pk=100. If the finder method is called from
> within the same
> transaction, then when the finder method on the home
> interface returned the
> remote object, it would reference the same entity bean
> instance in memory, where
> the name has already been changed. Therefore a call to
> getName would return the
> correct result for the transaction context, "Simpson". If
I don't know if this is the expected result as specified by
the EJB spec (I suspect that this is a specification hole),
but I would not call that result "correct".
In "design-by-contract"-speak: findByName( name ) has the
following postcondition: for each entity in the result set the
expression "result.getName().equals( name )" evaluates to "true".
If this postcondition is violated as in the case above,
I would call that result incorrect. It should be the burden
of "findByName" to ensure that only entities with the specified
name are given back as result.
> I would argue that the "problems" here are in the design of
> the application, not
> in the EJB spec.
No. The responsibility of "findByName" is to return all
entities with the specified name. If that can't be fulfilled
for implementation reasons (and I understand the implementation
problems well), the spec should at least state that
"calling finder methods after modifications of entity
beans in the same transaction yields undefined results"
or something like that.
Wolf Siberski
===========================================================================
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".
