DriverManager is mostly internal facility that we use to register different flavors of JDBC drivers with. For example, typically we would add the database-specific .jar file to the classpath, and in our startup code tell the DriverManager that the class to handle JDBC connections of this database type can be found .
in fact the methods are all static. usually we would do DriverManager.registerDriver.
Though there is the convenience methods in DriverManager.getConnection(), these likely pre-date the DataSource facility.
When we obtain a connection from DriverManager.getConnection() it is a single JDBC connection handle. and the connection is obtained when we call the method.
Where as the javax.sql.DataSource is an interface, that can be implemented in different ways (for example, the apache commons-dbcp project works to create a JDBC connection pool, where more than one connection are opened ahead of time (internally, possibly by calling DriverManager.getConnection().) and kept around. when your application wants to get a connection from the pool, you just work through the DataSource.getConnection() interface. But that is not to say all things that implement the DataSource interface need to be a pool of connections.
I think the DataSource as the thing to get connections from is preferred, because it is an interface, and readily allows for different application server containers to provide their own internal implementation, but your application code only needs to be built with dependencies against the DataSource interface.
Error: Keyboard not attached. Press F1 to continue.