My company is developing a JavaServlet based program. I came in about halfway through the initial bare-bones development, so some things were already in place. I'm a little at odds with my technical lead over the issue of property files. She doesn't want me to hardcode SQL Select statements in my code (exp: String query = "SELECT * FROM WHATEVER_FILE"). Instead she wants me to write the statement in an external properties file and do this: PropertyResourceBundle prp = (PropertyResourceBundle) PropertyResourceBundle.getBundle("resources.whatever"); String query = prp.getString("WHATEVER_STATMENT"); I am under the impression that a PropertyResourceBundle creates a collection of Strings. Our properties file has over 110 key / value pairs. Am I right in thinking that using a property file in this manner is creating a large chunk of objects that are memory-intensive, and it would be more efficient to just use a String in the code? ... and in actuality the properties file isn't even used in a dynamic manner. It's just her way of keeping all the select statements in one place. thanks,
We do use some stored procedures, but that's not the issue. I was just giving a general example. We select from other things as well, using our own defined classes (which extend HashMap, etc). I'm just interested in the comparison of speed and memory between the use of property files in this way as opposed to a simple string.
Hi. I use a combination of JNDI and .properties. I find the properties file a much cleaner way to manage systems since my codes can access settings without recompiling e.g. database access. You access the .properties like this : mybundle = ResourceBundle.getBundle("bundleName"); I don't know whether you can get the program to reload the "bundle" on the fly without restarting, but, hey , it's worth a try. Hope that helps.
Everybody is bringing up interesting points, but I'm still not coming across the answer I'd hope for. What I need is somebody to explain to me briefy the memory allocation of a PropertyResourceBundle. It seems to be a Collection of String objects, which would mean that a file with 110 key / value pairs would create an object containing 110 String objects, when the PropertyResourceBundle is initialized. To me this seems less efficient than a simple string when we talk in concepts of my original example. Does anyone know the answer? thanks,
hi all, i'm not that much experienced with anything like this. i've never used ResourceBundle and stuff (i'm scared of it :-)) i've used Properties instead. can't we use that here. of course we will have to look for escape sequence as we need to put sql in double quotes to get it as a single value. e.g. sql1 = "select * from abcd" sql2 = "select * from abcd where name='myname'" etc... please thro more light if i sound totally out of synch here regards maulin
110 strings does not seem like that much overhead. make sure you only load the resource once, i.e., static. no big deal..... Why aren't you using JDO or EJB CMP/CMR? Much nicer than straight SQL with JDBC.
hello i think the advantage of using the properites file to store the sql statement is to decouple your application from your database,certainly using stored procedure provide such benefit too,and using procedure can be more efficient than using sql statemen. as for if the 110-key properties files will exhausted much resource,i think it is not a deal to the application server,but if your server only have 32M memory,you should be careful. summarilly,i think both of the stored procedure and properties file are good solution,and don't hard code your sql statement!
As I understand it, ResourceBundle mechanism in itself is maintaining a static instance of the bundle internally. That is, it is a singleton internally, and so we can safely assume that a couple of hundred keys in the memory wont be much of a overload.
I agree with your boss on this one. Keeping the SQL as text, outside of the compiled code base, is highly advantageous. The concern regarding performance seems like pre-mature optimization to me... http://www.javapractices.com/Topic105.html