Please use the google group to ask questions - thanks.

I think the internal DataSource included in Ebean is very good (stable, fast). It has been around for a long time (about 6 years old) with the original DataSource code preceeding Ebean. It should handle database down/up issues fine as long as there is a hearbeat query configured.

Personally, I'm not a fan of the current apache DB Commons pool (in the way it validates connections).

I did some performance optimization about 2 years ago so it would not surprise me if it was a little faster than other DataSource implementations. Unfortunately I pulled out a stack trace mechanism for finding connection leaks so I should really try to put that back in as a configuration option.

It has preparedStatement caching so apart from the stack trace mechanism for finding connection leaks I'm happy with it. Although I should also make sure it gets registered with JMX (I need to check that).

You can dynamically "reset" the pool, and dynamically change the max pool size (which are things sometimes missing in other pools).

So yes, I think it is good and I intend to keep it 'feature rich' and suitable for production (with sufficient management features for an admin console such as "reset" and dynamic configuration).

Hope that answers your questions.
Cheers, Rob.

Actually to clarify:

Performance optimization of the DataSource are not specific to Ebean.

I'd say the PreparedStatement cache and the way it handles connection validation to be 2 of the main performance issues in a DataSource implementation but I haven't looked at the code for some time.

... but yes, it is definately possible a 3rd party DataSource implementation to be faster (and even better).