Do you expect to have an object cache or not? Scenarios 1 and 2 seem to
conflict on that.
Understand that scenario no. 3 will be replacing database hits with RMI
calls, just moving the bottleneck elsewhere. True, your system might be
capable of handling 5x more RMI invocations that JDBC hits, but you
still end up with a bottleneck.
Here are my suggestions (no warranty):
* If you want to reduce I/O activity on the database, consider throwing
a bigger RAM on the database server and letting it to caching. Typically
JDBC hits into an in-memory cache or no worse than RMI operations.
* If you want to put the cache on multiple servers to reduce any access
to the database (say connections are your bottleneck), then you have to
cache on both servers. Replicated caching might alleviate the problem if
all your servers access the same objects.
* If caching in the EJB server will allow you to have 4 Servlets servers
and 2 EJB server (just an example), as opposed to caching in the Servlet
requiring 8 Servlet servers, consider using EJB. Otherwise, consider
caching in the Servlet directly.
arkin
Yan Jing wrote:
>
> Hi, All,
>
> I have read this forum for a while and learned a lot from you. Now I am thinking to
>redesign my catalog management component using EJB and hope to get some advises from
>you.
>
> I am designing a B2B catalog based net marketplace solution (not product since I am
>working for an Application-Service-Provider company .:)), which supposes have a huge
>catalog content and allows buyers to browse/search the catalog with different price
>programs from different sellers, and allows seller or suppliers to change their
>catalogs and their price programs. I have three architectures in mind:
>
> 1. using JSP ---> Servlet ---> JDBC ---> RDBMS. Do object cache in both session
>level and application level. This way we have to code our own cache system.
>Perfomance should be OK. But no cache can share between different JVM, which
>increases the database hits. ( I used this architecture in my previous B2C commerce
>server product, the number of database hits was the bottle neck for performance. So I
>believe the object caching is neccessary.)
>
> 2. using JSP ---> Servlet ---> BMP Entity Beans ---> JDBC ---> RDBMS. This way EJB
>container will do the object cache for us. But since the catalog intends to be big
>(the number of EJB objects will be huge), I think the overhead from EJB container
>will be too much.
>
> 3. uisng JSP ---> Servlet ---> RMI caching server ---> JDBC ---> RDBMS. This way,
>time to market will be problem since we have to develop that multithreadeed RMI
>caching server. Also scalibity will be a protential problem.
>
> I know there have be many threads in the forum discussing related issues. But I
>still hope some of you have being dealing with the similar problem will give me some
>advises.
>
> Thanks in advance.
>
> Best,
>
> Jing
>
> ===========================================================================
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
