Hey guys, I am trying to decide between two design strategies and I'd like to get some feedback from you all.
I'm writing an e-comm system for an online DVD website. In my first EJB design I want to use non-transactional, read-only entity beans to represent the products (DVD's). I want to use transactional SS beans to perform order fulfillment and inventory updating. Essentially, when an order is submitted and the product inventory is updated in the database via direct JDBC, I want to manually invalidate the entity bean that corresponds to the product whose inventory was updated. Since the majority of requests from the website would be read-only, then it makes sense to have entity beans that are read-only.

My second design uses transactional entity beans in their traditional read/write form. This is a simpler design, but in this case even simple reads must wait in line to get the price of a DVD if someone else is submitting an order for that same DVD.

What do you guys think? I'm leaning toward the first approach.


SAF

Hi,
There are other alternatives too. You can look at the read-mostly pattern. If your application has exclusive access to the db and you have a single instance of the app server running you can use a read write entity bean with commit option A. That should work well i think
hope that helps
raghu

Correct. Commit option A assumes that the app server has exclusive access to the database and external updates to the database will never occur. But I really feel that having read-only entity beans that are non transactional can improve performance. I guess the best way to find out is to run some tests and determine the option that works best,

Thanks,

Raffi

you might be right. it would be nice if you posted the results of your study here.
good luck
raghu

What about using direct JBDC via a Session Bean to access the read-only product catalog for searches and traditional entity for read-write ?