A few comments: * The applicability of getting your connection from a DataSource goes beyond even Java EE, it's been the recommended way to get a Connection since at least JDK 4.
* It is always better to have the class which creates a resource manage its cleanup rather than scattering that between disconnected classes. To not close the connection in this class creates a hidden dependency to on something else far away. * In the Spring DataSourceTransactionManager case, closing the connection will not hurt. It will not really close the underlying connection. The next connection you get from the DataSource within the same Spring-managed transaction boundary will be another proxy to the same connection, using the same underlying real connection and the same actual database transaction. I assume this will be the case with other transaction managers as well, and I suspect this is intentional so that code using the DataSource is abstracted from the actual Connection details and does not have to know whether it is in a situation where it should close or not close the connection. (This is similar to the situation with connection pools...you are still supposed to close the connection...however this does not close the real connection, it just make it eligible to be returned to the pool). I can't find an authoritative source for this, but I think the best practice with DataSources and Connections is ALWAYS close the Connection when you are done with it, regardless of what kind of infrastructure you have going on at a higher level--it is the infrastructure's responsibility to ensure that your closing of the connection does not interfere with what it is doing. Cheers, Eric
