First off, I know the best-practice is to use a single database user account in your web app to take advantage of connection pooling to keep the app nice and responsive. However, due to the REQUIREMENTS (as in no changing this under any circumstances), I must authenticate each user with his or her database account.
The context is a warehouse management application that runs on Android, but gets its data from web services that I’m probably going to write in Grails unless a suggestion here shows me a tech more suitable for my requirements. Due to the nature of the application, the users would likely only need to authenticate once or twice a day, so I was thinking I could simply persist the Connections in a HashMap keyed by the hash code of the username concatenated with the password. That should allow the application to maintain the same or similar performance level as the best practice.
Now, my issue is in using the persisted Connection objects. I know that I will not be able to use them with GORM without a significant amount of customization, so I was planning on using them with groovy.sql.Sql, which works out well because most of the business logic is in PL/SQL packages anyway.
My question is how does the groovy.sql.Sql class deal with its Connection object? Will I run into issues of Connections being closed by it, or can I safely use my HashMap to persist the Connections?
groovy.sql.Sql will not close your connection. In the class spec you can find:
So SQL class is really if you want to do things by yourself, not trusting entirely on Hibernate. Although, I think you can use Spring’s UserCredentialsDataSourceAdapter for your solution. It uses ThreadLocal to set credentials for each thread, so the call to:
UserCredentialsDataSourceAdapter.setCredentialsForCurrentThread(String username, String password)would solve. There are other aproaches you could try here.