There is no standard or easy answer to your question. To answer you shortly (if you think this is shortly :-)) I�d say that it depends. It depends upon a lot of factors, like whether you have distributed transactions or not, depends upon the transactions logic and complexity (basic CURD operation are easier to handle than a transaction that spans a lot of logic), it might also depend upon integration with other systems or legacy applications, etc. Probably in your case one of the first important decisions to take is about the concurrency strategy you want to implement. If your transactions are pretty simplistic in nature, requiring only basic CRUD operation, then you should probably consider allowing the database to handle them. In this case you might not need an application server at all; you just need a powerful database engine and an efficiently clustered web server. If your transactions on the other hand are logically complex (but not distributed still) then you might consider the option of handling the concurrency "outside" of the database, at the container level. This would be in this case more efficient than handling the concurrency inside the database. The secret is to use caching data as much as you can. But these kinds of solutions are usually outside of the j2ee specs and they represent vendor specific solutions. As an example I�d like you to look at the read-only concurrency strategy and optimistic concurrency strategy that weblogic provides. They both benefit of the fact that the data could be cached between transactions and this is in a totally contradiction with what the silly j2ee specs say (accordingly to j2ee each any transaction starts with ejbLoad and end with ejbStore. Yes it always works but there is no way to provide any caching and it will overkill you application). Finally if you have distributed transactions, or if you don�t feel happy with any of the solutions above, then think that messahing is one of the key successes for designing this type of highly available and mission critical applications. You can turn your attention to other messaging systems like MQSeries, or you can implement a message fa�ade with ejbs. However the choice is, you�ll definitely need a powerfull database and a very optimal and efficient cluster. Regards.
A few thoughts off the top of my head. Design and code your application to be distributable, as you will probably cluster it or the EJB server may choose to ditribute the beans. So, no non-final static variables, keep away from singletons ...
Unless there are good reasons why you shouldn't, use only stateless session beans (and MDBs if needed) and optimise the connection pool.
Keep your transactions short, do not fall into the trap of keeping them open during user input! Use CMT in most most cases.