Jing,
The timing of your post is very interesting to me. I happened to be looking
at the Corio web site earlier in the day. You guys are doing some very
interesting stuff.
You are correct that e-catalogs are a great application for object caching.
Implementing approaches #1 and #3 is certainly do-able, but why would you
want to when there are commercial implementations that provide those
services for you? There are at least a couple of app server vendors that
allow you to do #2 in a very natural way.
<vendor>
The two vendors that I'm aware of with the most solid transactional object
caching implementations are Gemstone and Persistence. Gemstone has already
been mentioned in this thread, so I'll say a word about Persistence.
Persistence PowerTier is an EJB app server that provides a model-driven
approach to creating entity beans. This automates the grungy work of
developing and maintaining your own persistence services. It also enables a
transactionally aware cache that automatically synchronizes modified entity
beans across server instances and maps to popular RDBMSes.
</vendor>
Hope this helps,
...Jim
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Yan Jing
> Sent: Monday, March 20, 2000 5:26 PM
> To: [EMAIL PROTECTED]
> Subject: Question about catalog management component using EJB
>
>
> 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".
