----- Original Message -----
From: "J. Matthew Pryor" <[EMAIL PROTECTED]>
> > The latter requires so much overhead (and serialization) that any
benefit
> > derived from Option A (entity caching in the container) is lost.
> On what information do you base this statement ? Is this just anecdotal;
> concrete studies with data would be most instructive.
In this particular case, I *do* know what I am talking about. :-)
> If this is truly the case then there seem to be a lot of vendors out there
> wasting someone's money selling & building shared caching technology.
I don't believe there *are* a lot of vendors offering this "feature". BTW,
we're not specifically talking about shared caches (ala Gemstone, IBM,
Persistence?), but rather the ability to develop applications that do not
have to perform an ejbLoad at the start of every transaction.
I'd be happy to debate an honest vendor if they state that clustered entity
caching is faster than reloading the bean at a transaction boundary.
> If you are in a legacy data scenario where it is hard to tell when source
> data has changed, I can see definite tradeoff that may zero each other
out,
> but there are many situations where clusters with replicated entity data
> caching should be a realistic objective ..... or don't you agree ?
No, I guess I don't. I believe it is a utopian objective. Show me where it
works that way. You would be foolish to treat any entry point to your data
as the *only* entry point. What do you do 5-10 years from now when EJB is
superseded by (insert new idiom here) technology? What if your company
merges with a company that is a Microsoft shop, and uses COM objects to
access the database?
I don't live in Utopia, because my customers don't.
jim
===========================================================================
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".
