Will EJB help Scalablity, Availiblity and Preformance with/instead of JDO?

[Graham Cruickshanks]

Hi,
I�m looking for some experienced Peer J2EE architect advice.
I�ve about 35 fined grained JDO objects, These map to the row level in each row of my database. There is about 6 different object graphs that represent larger entities.
From looking through best practices with EJB entity beans, It recommends that Entity Bean should be Coarse Grained Objects and to use the �Composite View� design pattern. The Composite View pattern uses database access object I.e. JDO.
My application preformance and scalablity are untested at the moment but I know it needs to support between 1000 and 3000 clients concurrently polling to see if they have any notification about once every 20 seconds via a webservice. Also Interactions of about 1 a minute will be sent to the server for processing. These interactions are processed asyncronessly.
Currently the architect is
Interactions Interface:
httplistener -> Axis -> message queue (JMS)-> processor selection (java obj) -> process (java obj) -> entitymodel (jdo) -> database
Notification Interface:
httplistener -> Axis -> message queue (JMS)
So here is my question.
If I convert my app by extend its architect to include EJB objects like so
Httplistener -> Axis -> message queue -> processor selection (stateless-sessionbean) -> process (stateless-sessionbean) -> entitymodel (Coarse Grained Entity EJB with composite JDO) -> database
From experience, how will this affect non-functional requirements:
Scalablity, Availiabity, Preformance and security?

[Lasse Koskela]

Considering that the use cases you mentioned essentially spell out "stateless", I would say that EJBs have probably not much to offer except declarative transactions. On the other hand, replacing the POJOs with EJBs probably won't do much harm to your performance either (assuming you're using local interfaces and caching the bean's home interface). Maybe you should just "stay out of harms way" by waiting for a real reason to make changes instead of predicting them?
I would however take another opinion on this.

[Graham Cruickshanks]

Thanks for answering.
I'm still confused on the applicability of using EJB. All the Entity Bean patterns recommend 'Coarse Grain Object�, a level of abstraction above your database schema.
So you end up having all the object instances with the DAO�s returns Graphs of POJO�s for the Value Objects.
For a non-functional requirement that J2EE is sold on my question in this context would be:
Performance :-
With so main instances of POJO�s recommended for performance. How can a Coarse Grained Entity bean help at all? It may do passivation/activation and pooling but that just seems like a pointless layer.
Scalability :-
EJB increases scalability by helping control object lifecycles, but once again it seems to add a (on surface) pointless layer. For passivation/activation to be effective you surely would require long running sessions that can be shifted out to disk and back into ram.
Availability : -
Clustering, Yes it would help here as J2EE providers have a mature framework for this, but most JDO implementations for DAO�s now come with clustering.
Security:-
Excellent support, But I�m not sharing my Business Objects with departments or other projects. In my experience this rarely happens, so good if ever needed.

Architecture applicability for EJB seems to be more extreme cases than the norm?