William Louth wrote:
>
> Option 'None'. OK. So you would not have any problems with a container
> returning a remote reference to an entity bean that does not exist in the
> database. Only when you call a business method on the remote will you client
> detect the error. This will result in confusing client exception handling
> code. Would it not be easier to have already captured this exception and
> reported it prior to normal business method invocations. The only time that
> this would be benefical (optimization i.e. no verification sql statement)
> would be when you were assured that the primary key did exist in the
> database at the time of transactional work. Unless the primary key was
> obtained in the same transaciton there really is no assurance since many
> transactions could be executing simulatenously in any number of processes
> both ejb and 'non-ejb' based.
William,
Sorry to bicker, but I think there are quite a few situations where having
the findByPrimaryKey method simply return an object reference without attempting
to verify the existence of the object is useful. (That's why I added this
feature to our product.)
Consider two cases:
1) The entities are well known and stable. For example, if you have entities
representing geographical locations, these tend to be fairly stable. Therefore,
having your call to:
Country france = CountryHome.findByPrimaryKey("France");
not actually verify that Russia is a country is pretty reasonable IMO. Note that
if for some reason France is no longer a country, then your first usage of the
entity will throw an exception.
2) You have heavy concurrency. In this case, it is very possible that between
your findByPrimaryKey and your use of the entity, that the entity be removed.
Of course, if you are running against a database that provides true serializability,
then this cannot happen, but:
a) The major databases have "trouble" providing true serialization, and
b) True serialization is computationally expensive, and probably not needed in
many applications (which provides some rationale for (a)).
-jkw
===========================================================================
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".
