Issues regarding using EJB - Entity / Stateless

My web application may have about 10000 logins at a time and at my design stage should i decide about using all throughtout only stateless session bean with methods to connect to databse being informix9.2, and invoke any kind of DML statements directly, rather than having a CMP/BMP Entity bean.

My end user may have the least of client hardware config and must still succeed in using my web application.

My application deals with blobs and images (basically MPEG files) the amount of load on the Internet Server as well and my end users CPU time must be considered now.

My concern :

If i decide on a CMP Entity bean - saves a lot of my efforts of transactions handling and rest. But i am worried about my Internet service mgr as well as my application server WebSphere as to whether the load of 10000 logins approx. multiplied by say 10 CMP Entity beans . what will be the scenario then ?. Server crash

Will it be efficient in perfomance and the best proposal to have a stateless session bean performing the DMLs in methods and the developer handling the transactions.

For such heavy transaction based and highly used concurrent users application is CMP/BMP Entity bean suggested to do the DML on database.. or can stateful session bean be of any good help with any work arounds.

or

Stick to safer design 'Stateless session beans'

[1403 byte] By [sheena_abraham] at [2007-9-26 2:28:47]
# 1

I think this is a fairly major decision since whichever way you go it will be difficult to turn around later and switch. Have you tried any hard benchmarking to see what the real story is? I know IBM provides a performance test app freely, you probably wouldn't have to spend too much time adapting that to your scenario. IMHO, I would probably be inclined to agree with you but it's always better to get some hard evidence.

swatdba at 2007-6-29 9:45:01 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...
# 2
A good application server supports pooling of Entity Beans, which means you will probably not have 10*10000 beans in memory at one time.Of course there will be a lot of passivating and activating but it depends on the activities triggered by the users.
ellipsustompa at 2007-6-29 9:45:01 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...
# 3

What is 'the good Application Server' that u would recomend in your experience for a web application like mine. Thou there is the bean Activation and passivation... what happens to the thread links of each of these beans? destroyed/alive - The theory not too sure about regarding this. Can u help me with any online help available.. any web site... any book ?

Thanks for the reply

sheena_abraham at 2007-6-29 9:45:01 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...
# 4

some clarifications:

1.You can have a BMP model and still let the container do the transaction part.

whether you want to handle the daabase access in your application (BMP) or let the container do it (CMP) is dependent a lot on the application you are developing .

you could go for BMP and CMT(Container managed transaction) if you dont want to handle the transaction issues ...

2.If you really want to have the client information to be stored across two or more client requests than go for Stateful else stick to stateless .

3.Most of the Application servers provide means for optimizing the number of entity beans in cache . Make use of it . I feel its not necessary to have 10000*10 in pool for thousands of logins...

hope this helps ..

mohan

mohanN at 2007-6-29 9:45:01 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...
# 5

Any AS should be "good" meaning it supports pooling, else it would be useless to use it, just like mohanN writes.

I recommend Mastering Enterprise JavaBeans II by Ed Roman.

You can download a couple of chapters at

http://www.theserverside.com/resources/ejb_review.jsp

ellipsustompa at 2007-6-29 9:45:01 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...