<vendor sarcasm>
Naaah, you guys can feel free to hang out and bicker all you want :)
We'll make sure to keep Evan's nose to the grindstone.
</vendor sarcasm>
Dave Wolf
Internet Applications Division
Sybase
----- Original Message -----
From: "William Louth" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 22, 2000 11:16 PM
Subject: Re: findByPrimaryKey spec. question
> Jonathan,
>
> Sorry to bicker but is "The only time that this would be
benefical....would
> be when you were assured that the primary key did exist in the database at
> the time of transactional work" the same as "entities are well known and
> stable...findByPrimaryKey("France")".
>
> <note-to-jonathan>
> stop bickering on this mailing list and back to working on our next
release
> </note-to-jonathan>
>
> William
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan Weedon
> Sent: Wednesday, November 22, 2000 12:05 PM
> To: [EMAIL PROTECTED]
> Subject: Re: findByPrimaryKey spec. question
>
>
> 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".
>
>
===========================================================================
> 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".
