I we are in the process of restructuring a web site. The web site is an e-commerce site. The user can go onto the site and read news articles (editorial content) and from these articles will see links to our products. This is also vice versa, if they are looking at product they will also see links to aricles (editorial content). So we created targeted selling.
However my question is the how best to design this site with EJB. All the aticles (editorial content) and products will be store in a database. But how do i model them in an ejb environment. For example i think Entity beans would be to much overhead. Because the content is rarely updated if not at all. So 99% of the time will be spent retrieving this data. But new data (eg new aricles,new products) will be added all the time. Because of the retrieval process i need a cache mechanism so that i am not going to the database all the time. So where to i implement this cache.
Basically the same products and articles need to be see by every user. However if the data is updated this needs to be seen be everyone. So i was thinking of a StatelessSession bean that queries the database and stores java object in its self that represent the data from the database.
Any ideas, and experience. They type of website are very common on the web so someone must have do this sort of thing before.
Since your catalog is read-mostly you may want to consider using entity beans so that you get long-lived caching. BEA WebLogic can do some low-end caching for you by flipping the dbIsShared=true switch on, which results in some pretty massive performance gains since you don't have to hit the database at all once the data is loaded into memory. Other app servers have more advanced transactional in-memory distributed shared object caching algorithms as well - check with your vendor.
This may be an example of a situation where NOT using entity beans may significantly lower performance.
A common web site that uses entity bean caching? TheServerSide.com. Pretty fast, aint it?
Thanks for the answer it's made me think about the problem a different way (loved your book by the way when's the next one comming)!
So then you feel Entity beans are the way forward. So for example if i have 50k+ prducts and say 1000+ articles (editorial content) in my database is it acceptable to have all of these cached in memory as entity beans at once (eg 51,000 entity beans just for this section of the site). Considering i will have lots of other EJB's floating around such as "accounts" "orders" "utilities" etc. I am think this will be fine because they will get recycled by the containers LRU caching mechanism. Is this correct or is this a problem
If this is the case, i was thinking of having methods on my (lets call them product and editorial) entity beans to return aggregate classes. Instead of me having to call getId(), getName(), getDescription() etc. I will return one class that contains all this information. Reducing remote calls. Is this the right way of thinking.
Also do you or anyone else have an recommendation for the best container for this sort of problem. Also i have to utilise a C++ based personalisation engine and i was think along wrapping it up in corba and exposing it as an ejb. So the container has to be able to handle this too. What do you think of Inprise app server.
cheers hope to here soon.
Ps. i was looking at the code for the Java Pet store demo from the ejb blue prints. They sort of have this problem tpp. But they use a stateless EJB to get all the products and it goes to the database every time they ask for a product. No caching, surly this is not a good design to be premoting.
..Moreover, you can define a timout after that the WL refreshes the cache with the DB.
It is useful if you have asynch made some changes to the
WL defines also read only Entity which are fully clustered