Announcement Announcement Module
Collapse
No announcement yet.
Static inner RowMapper class use in query(String, RowMapper) method Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Static inner RowMapper class use in query(String, RowMapper) method

    Spring reference document and all Spring books show an example of JdbcTemplate.query(String sql, RowMapper rowMapper) method using either anonymous class or inner static class implementing RowMapper with new class instantiation in the method. Both usage patters create a new instance of a class on every call to query().

    What are the downsides of using an inner static class, assigning it to private static attribute in the initializer and using this variable in query() method?

    Reusing the same instance of the class gives the benefit of eliminating an extra class instance on every call and I cannot think of any downsides. The mapper class has to be stateless anyway and cannot access outer class instance variables (since it is static). The impact of creating a short lived class is not that high (since it would never transition to the old generation heap) but if I can eliminate instantiation without any negative effect I'd rather do that.

    Something like this

    Code:
    public class SampleDao extends JdbcDaoSupport {
        private static final RowMapper<Actor> actorMapper = new ActorMapper();
        private static final String sql = "SELECT first_name, surname FROM ACTOR";
    
        public List<Actor> getActors() {
            return this.getJdbcTemplate().query(sql, actorMapper); // Reuses ActorMapper class instance
        }
    
        private static final class ActorMapper implements RowMapper<Actor> {
            public Actor mapRow(ResultSet rs, int rowNum) throws SQLException {
                Actor actor = new Actor();
                actor.setFirstName(rs.getString("first_name"));
                actor.setSurname(rs.getString("surname"));
                return actor;
            }
        }
    }
    I went through all Spring books covering DB access and every single one uses new RowMapperImplementation()

  • #2
    I'm assuming that in the generic case:
    - you would end up with threadsafety issues.
    - you wouldn't be able to change from the singleton scope to something else via config.
    The first point is a potential bug, the second point is just around design/maintenance.

    Comment


    • #3
      Originally posted by whyBish View Post
      I'm assuming that in the generic case:
      - you would end up with threadsafety issues.
      - you wouldn't be able to change from the singleton scope to something else via config.
      The first point is a potential bug, the second point is just around design/maintenance.
      I do not anticipate any threading issues in this type of static class. It does not have any state, all variables are local. Even if the class is changed from singleton to prototype it will work the same way as static RowMapper contains self contained logic. The same static RowMapper class can be used by multiple instances of DAO class, at the same time.

      Comment


      • #4
        I totally agree, shouldn't pose any problems that I could see

        I do not anticipate any threading issues in this type of static class. It does not have any state, all variables are local. Even if the class is changed from singleton to prototype it will work the same way as static RowMapper contains self contained logic. The same static RowMapper class can be used by multiple instances of DAO class, at the same time.
        I agree, there's no reason why I could think of that this is a bad idea. Another consideration is to make the inner classes first class in their own class file and make them public. This way you are actually broadening the configurable possibilities rather than narrowing them. You could have them annotated with @Component, injected by spring by @Autowired which would allow for use of different mappers for different DB vendors etc (think field case-names etc...).

        Reasoning that "threading issues" could arise is nonsense, there's no threading issues that could come out of this. Even if there were two instances accidentally created, who cares? It's not going to harm anything. These classes are tiny and don't pose a problem being all loaded at once. If you have 100 tables, who cares about 100 classes being loaded?

        Comment

        Working...
        X