I have an application that is already using the Spring Framework and Spring JDBC with a DAO layer using the SimpleJdbcTemplate and RowMapper classes. This seems to work very wel
I guess you have reasons for not using an ORM, which is the ideal tool for this kind of problem.
The problem with multiple connections is the recursive call to another DAO. To avoid consuming additional connections, Account objects should be to be retrieved later, after the project instance has been fetched. When fetching the Project, the accountIDs are also fetched, but not "instantiated" to account instances - they remain as a list of IDs, which are then populated after the project DAO has done it's work.
For example, you can build a custom List type that takes a list of IDs and a DAO implementation. The list is populated with just the IDs in the ProjectRowMapper and assigned to the project's accounts property. The IDs are private to the list - they are not the "contents" of the list, but a means to produce the real contents later.
Once the Project DAO has fetched the projects from the RowMapper, it can then instruct the list to then fetch the accounts for the IDs that were saved in the list. The accounts are fetched as s non-nested operation and so the whole process only uses one connection at any time. Yet,the fetch is done within the scope of the DAO method, so the fetch is done eagerly - so there are no lazy-loading issues to deal with.