Q:

Scope and Entity class

I am new to JSF and EE and trying to understand the best approach to make the right design decisions for a project. I am working on my own, relearning after 20+ years and pursuing a very ambition business idea.
My question relates to system overhead and performance implication by the design choices I make.  I am using all of the latest with EE7, JSF 2.2.6, NetBeans 7.4, Glassfish, etc. If I don't have the latest I will upgrade as I go.
It is a pretty big question I guess, as it relates to the full path from web container scope, ejb type and EM vs EMF. I've read a lot and believe I understand the philosophy but probably not fully.
My app involves (hopefully 1,000-100,000+) simultaneously logged in users that will be connected for 4-6 hours but only making requests every 10 minutes or so. To start, it will probably only be 100 or so and my short term goal is to just get something working and improve from there. I would however prefer to make the right decision upfront. 
From my reading my understanding is that most would use @SessionScoped backing beans (while the user is logged in), @Stateless Managed Beans and probably a container managed Entity Manager.
Although this seems the easiest to program my interpretation is that the overhead would be great:
- I will have as many session scoped instances as I have connected users; 
- as many stateless EJB's as I have users because they are injected by the SessionScoped bean
- one massive cache in the Entity Manager as every user has a different interest in data. 
- I also assume web and ejb sessions are equal to java threads rather than just some stored data.
Is this understand close?
Although much more complicated I assume a better performing system would involve my own session control, request scope beans, stateless ejb and application managed entity manager (emf) where I only preserve the cache when it is a long standing transaction. This would create a pooled environment with less instances and thus threads, swapping, disc caching, etc.
I've read substantially, built a test environment using a lot of BalusC suggestions and have a reasonable but theoretical understanding of most things from JSF lifecycle on. As much as the platform of JSF and EE seem like a good decision the learning curve is a little overwhelming.
Any clarification to point me in the right direction would be appreciated. 
Thanks in advance,
John

A:

Is this understand close?

partially.

I will have as many session scoped
  instances as I have connected users;

yes, this is correct. but this number is "virtual" since container can serialize some of them to disk (to be exact, entire session is serialized) on LRU algo and a threshold.

as many stateless EJB's as I
  have users because they are injected by the SessionScoped bean

it depends on container implementation. it is reasonable to say they implemented this mechanic the most efficient way. the worst case is # of SessionScoped bean (injected EJB) = # of EJB = # of user.

one
  massive cache in the Entity Manager as every user has a different
  interest in data. 

cache is configurable, but IMO you shuold consider the tradeoff between cache size (add more RAM?) and performace (what if there is no cache? what if the cache contains every entity?)

I also assume web and ejb sessions are equal to
  java threads rather than just some stored data.

no, EJBs (stateless, stateful and singleton) are just data. Scheduled one and MDBs are more similar to what you think (they are not thread but a thread is created by an executor to invoke them).

Although much more complicated I assume a better performing system would involve my own session control, request scope beans, stateless ejb and application managed entity manager (emf) where I only preserve the cache when it is a long standing transaction. 

it depends on how you configure application server, persistence provider and how you develop your business logic controller beans. however, every point in this list can be configured/optimized later (little more effort on refactoring controllers).

This would create a pooled environment with less instances and thus threads, swapping, disc caching, etc.

EE stack has exactly this point of view. threads are pooled and reused, they are not user-specific, but request specific. a pool of 10 threads can reasonably serve 100+ users.

I've read substantially, built a test environment using a lot of BalusC suggestions and have a reasonable but theoretical understanding of most things from JSF lifecycle on. As much as the platform of JSF and EE seem like a good decision the learning curve is a little overwhelming.

from what you are asking it is clear that the learning curve is not so overwhelming for you :)
although EE stack is really heavy compared to other technologies, it is scalable, flexible and extendable. like you, i think it is a good choice.

in my experience, the worst thing affecting performance is network speed and traffic. in some case i saw loading homepage central image taking much more time than executing a complex report with thousand of rows.
however, don't worry (too much) about optimization, because premature optimization is the root of all evil

