| Caveat: I'm no JDBC expert. That makes two of us. :-)
| The answer is likely driver dependent as Connection (the source | of PreparedStatement instances) is an interface and it doesn't | seem to be part of its contract that it return cached instances. | In fact, whether or not using a PreparedStatement results in | precompilation is driver dependent. A driver that doesn't | support precompilation probably hasn't a lot to gain by providing cache. | | MySQL Connector/J 3.0.9 doesn't seem to do either precompilation | or caching of PreparedStatments. So it may help, and probably doesn't hurt? | I can tell you that your application level cache (below) isn't | thread safe if access to this method isn't synchronized. HashMap | isn't thread safe and neither is the "if (psMap == null) psMap = | new HashMap();". | | A correct impl would instantiate psMap (as final) in the | constructor or initialize it at class load time if it's a static. | For thread safe Maps see the Collections utility class for | wrappers or, better, Doug Lea's util.concurrent package | http://gee.cs.oswego.edu/. I'm interested in the topic of thread safety here, I'm not very well versed in this area : What would be the result of un-thread safe access at "if (psMap == null) psMap = new HashMap();" ? The Map would be instantiated twice and one of the instantiations would 'win', right? Possibly the Map could be holding one PreparedStatement, and be replaced by the new empty map... resulting in the re-compilation of one PreparedStatement at some future point? Could something worse happen? Same question of unsynchronized access to the HashMap. What should I be concerned about happening? Seems like maybe two threads would try Map.get(key) and both get null back, then both create the same PS and place it into the Map, where one would 'win', right? Or is there something deeper there? Thanks! :-) ~akb | | --rob | | > -----Original Message----- | > From: A. Kevin Baynes [mailto:[EMAIL PROTECTED] | > Sent: Sunday, January 11, 2004 12:19 PM | > To: [EMAIL PROTECTED] | > Subject: [Juglist] JDBC Connection and PreparedStatements | > | > | > | > I'm using JDBC and PreparedStatement. | > | > Is there a need for me to manually cache PreparedStatements, | > or is that functionality built into | > Connection.prepareStatement(String) ? | > | > I'm wondering if the following is overkill... | > | > I have a custom Database object with this method : | > | > public PreparedStatement getPreparedStatement(String sql) { | > | > if (psMap == null) { | > psMap = new HashMap(); | > } | > | > PreparedStatement ps = (PreparedStatement)psMap.get(sql); | > if (ps != null) { | > return ps; | > } | > | > // didn't find ps | > ps = getConnection().prepareStatement(sql); | > psMap.put(sql,ps); | > | > return ps; | > | > } | > | > tx, | > | > ~akb | > | > | > _______________________________________________ | > Juglist mailing list | > [EMAIL PROTECTED] | > http://trijug.org/mailman/listinfo/juglist_tri> jug.org | > | | _______________________________________________ | Juglist mailing list | [EMAIL PROTECTED] | http://trijug.org/mailman/listinfo/juglist_trijug.org _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
