> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of James Cook
[snip]
> 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.
>
But wouldn't such vendors include those named above who do have shared cache
technology that can also be used to perform clustered EJB caching (among
other things)
I guess I must be misunderstanding how EJB makes this so much harder (no
doubt it is already hard with any replicated, cached "object" data). I do
not personally know of any systems that are in successful, large-scale
production using replicated, clustered, entity beans, so in this case I *do
not* know what I am talking about ;-)..[ We use our own EJB-alikes &
toplink ]
[snip]
> 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.
>
I take your point, but surely it is reasonable to assume that in many cases
people won't just ram stuff into the database. Surely we have concepts like
abstraction, interfaces, proxies, adapters etc to ensure that access to
resources can be marshaled or controlled to some degree. I have no doubt EJB
will seem like COBOL one day (5-10 years seems optimistic ;), but that's
doesn't mean I won't want to repackage it, rather than just circumvent it &
go straight to the database.
The (overextended admittedly ;-) extrapolation of that logic would say that
Oracle shouldn't cache anything either, because I may well chose to write
directly to the files that make up the Oracle database? (yeah, yeah, I am
stretching it)
Thanks for your insights, large scale production-hardiness is a necessary
antidote to too much marketing hype.
jmp
===========================================================================
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".
