Cedric Beust wrote:
>
> 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.
I've enjoyed the debate, (except when at one point it seemed to be turning into
a vendor-bashing exercise) and I've learned a lot so don't stop until you've
cleared up the issue.
> 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"?
There really should be no doubt on this issue. It's pretty fundamental that an
Entity Bean exists when and only when the underlying database data exists, so a
container that allows an Entity Bean to be instantiated without checking is
non-compliant. Of course, if using optimistic locking it is perfectly valid to
defer checking until commit.
Are there any worthwhile scenarios where this deviation improves performance
significantly? (Jonathan's is too contrived to be counted as "worthwhile").
Ian McCallion
Alexis Systems Limited
Romsey, UK
===========================================================================
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".
