My 2 cents, though I am not an expert:
* Active Users != concurrent users. To have 1000 open conversations depending on usage patterns you will probably have to have 100000 users.
* A DB connection is only ever held for the duration of a single request. So you need only a fraction of that.
* Some thousand objects (beans, entity managers) can easily live in memory - which performs much better than a dozen db accesses on each request.
* Load balancing can distribute load on several application servers (entities cached in conversation) much better than the database can scale (no entity caching, much more db queries, single hot spot)
I'm no expert too, but here's what i think :
Stateful EJBs (and database connections) are managed by your EJB container. So, let's say you use JBoss AS :
If a database connection is needed, JBoss will look into its connection pool to see if there's one available. The number of connection is a parameter you can define, but you certainly won't need more than 10, unless your application has very heavy concurrency requirements.
As for EJBs, every container has its own algorithm to manage them. But generally, there will be a fixed number of instances available, and the container will serialize/deserialize the state of your SFSBs when needed. You'll never need 1000 instances for 1000 users!
Hopes this helps,
Yes, the most important thing to keep in mind is that the persistence context will save you. The persistence context is the most lightweight data resource you can have. It's really nothing more than a glorified HashMap, but what it allows you to do is save one of those database connections that would be needed by skipping the read. Know that it only uses a database connection when necessary and disconnects from it after the request.
The other thing to keep mind is that conversations should be as short as possible for non-authenticated users...almost to the point where they are just for immediate operations. Authenticated users get much longer conversations, but you can even tune those based on use case.
As a disclaimer, keep in mind that storing any state has to be treated wisely on large systems. Seam doesn't give you all the answers. It just puts you in the right paradigm. You pay those people to think about memory management for a reason.
Thanks for helping out.