Ben Engber wrote:
>
> Thank you Martin (and Ken), that was indeed a good article.
>
> If I understand correctly, then, in the case of BMP I can use proprietary
> DB-pooling for data access, and use the Instance Pooling property of EJB to
> implement row level caching.
Not really. You can use JDBC2.0 DataSources for DB-pooling, which would
not be proprietary. (This is how you *could* do, but of course your
EJB-server have to support JDBC2.0 for it to work.)
> I know that more sophisticated caching capabilities are a property of the
> appserver. How exactly do those fit with EJB? Would it be via CMP and
> fancinesses in the Deployment Descriptor? If so, how do I control things
> like explicitly expiring certain rows from the cache -- it seems you'd need
> an API call.
This should be managed by the container I believe without too much
divine intervention. Tengah does this for example.
> Or should the appserver offer caching and other services as APIs
> independent of EJB? In this case I'm still a little perplexed about the
> role of EJB (given that I have connection pools). Is it simply to more
> effectively manage memory or other resources because the container controls
> the number of bean instances open?
Well, that is one side of the story. IMHO you gotta see the Big Picture
here, which (for me at least) is that at last there is a standard
component specification that will let you build and componentizise
applications and deploy them on a wide range of servers. Kinda neat,
aint it? :-)
And then there's a about a gazillion other facets, but you get the
idea...
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
