Когда использовать @Singleton в ресурсе Джерси

У меня есть ресурс Джерси тот доступ база данных. В основном это открывает соединение с базой данных в инициализации ресурса. Выполняет запросы на методах ресурса.

Я заметил, что, когда я не использую @Singleton, база данных открыта в каждом запросе. И мы знаем, что открытие соединения является действительно дорогим правом?

Таким образом, мой вопрос, я должен указать, что ресурс является одиночным элементом, или действительно лучше сохранить его в на запрос особенно, когда ресурс соединяется с базой данных?

Мой код ресурса похож на это:

//Use @Singleton here or not?
@Path(/myservice/)
public class MyResource {

    private ResponseGenerator responser;
    private Log logger = LogFactory.getLog(MyResource.class);

    public MyResource() {
        responser = new ResponseGenerator();
    }

    @GET
    @Path("/clients")
    public String getClients() {

        logger.info("GETTING LIST OF CLIENTS");

        return responser.returnClients();
    }

    ...
    // some more methods
    ...

}

И я соединяюсь с базой данных с помощью кода, подобного этому:

public class ResponseGenerator {
    private Connection conn;
    private PreparedStatement prepStmt;
    private ResultSet rs;

    public ResponseGenerator(){
        Class.forName("org.h2.Driver");
        conn = DriverManager.getConnection("jdbc:h2:testdb");
    }

    public String returnClients(){
        String result;
        try{
           prepStmt = conn.prepareStatement("SELECT * FROM hosts");

           rs = prepStmt.executeQuery();

           ...
           //do some processing here
           ...
        } catch (SQLException se){
            logger.warn("Some message");
        } finally {
            rs.close();
            prepStmt.close();
            // should I also close the connection here (in every method) if I stick to per request
            // and add getting of connection at the start of every method
            // conn.close();
        }

        return result
    }

    ...
    // some more methods
    ...

}

Некоторые комментарии к лучшим практикам для кода также будут полезны.