As far as Hibernate is considered we did a EJB vs Hibernate analysis and found out that performance for connection pooling and transaction management using Hibernate was not up to mark. Moreover in our design ORM was not as valuable as transaction management (so we chose Session EJB).
How did you make this comparison? Comparing EJB vs Hibernate is like comparing Apples to Monkeys. It doesn't make sense, EJB is primarily for building Distributed Components and Hibernate is an ORM tool... the use of one does not exclude the other. If you are saying that you compared Entity Beans to Hibernate then that is a valid comparison, however I doubt you would have made the conclusion that you did.
Let's talk about the two things you mentioned: Connection Pooling and Transaction Management...
Regardless of EJB vs. Hibernate, Connection Pooling can and should be managed by the Application Server. Both EJB (here I am talking about Session Beans using straight JDBC or Entity Beans) and Hibernate can use a JNDI Datasource which is created and managed by the Container.
Transaction Management is also a fairly trivial subject for the type of application you describe. I assume you only have a single datasource and no need for distributed transactions. This is the case in 99% of J2EE Applications and is actually fully supported by the standard JDBC specification... no need for JTA or XA Transactions, no need for EJB Transaction Management (though this makes transaction composition easier sometimes).
So basically what it comes down to is not EJB vs. Hibernate... but plain JDBC vs. Hibernate. This is a valid question and the answer really depends on your particular development needs. Do you have a Rich Domain Model with complex associations and little desire to hand-write SQL? If not then Hibernate probably isn't for you... however I wouldn't necessarily recommend going down the straight JDBC path either. Take a look at the Apache IBatis Project
... it is a good mix of pedal to the metal SQL and ORM Mapping... at least I quite like it. Plus, as Stan mentioned, it is worth it to look into Spring for its abstractions on top of plain JDBC or even ORM tools like Hibernate and IBatis.
Finally, I would like to touch briefly on the subject of performance. It actually doesn't seem to me (based on your description) that this application needs much in the way of performance. In reality concurrent users is not a very good indication of total volume. What we actually want to know is the total number of concurrent transactions that the system will be processing. So let's take a shot at that metric with some concrete (and made up) numbers...
Number of Concurrent Users = 500 (shooting high here)
Average Think Time between Requests = 10 seconds (we need time to think before answering a question right?)
Average Transactions Per Second Per User = .1 tps (based on 10 seconds think time)
Average Total Transactions Per Second = 500 users * .1 tps per user = 50 TPS
So even being pretty conservative with these numbers, you are looking at 50 TPS. My thought is that the production volume will actually be much lower than this (ie. less users and probably a greater think time). As you can see, this isn't very high and I personally don't think you should be overly concerned about performance at this point in time. Put together a solid design, execute on it in build, and setup some time throughout the project to test performance and adjust the code as necessary. Rinse, Repeat.
[ April 27, 2006: Message edited by: Chris Mathews ]