Hard to say without an understanding of your data model and access profile, but
consider representing the catalog as an EJB, a catalog item as a dependent non-EJB
object and a usage-dependent filter as servlet code.
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".
===========================================================================
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".
