JDBC Architecture

This is my first stab at JDBC. I've written a simple class that accesses our database and prints out a list of records from a file. In order to make it work, though, I had to hard code the IP address, the user name, and the user password. I've heard of something called a Property file that I could store the IP address in and retrieve it so that I could softcode the IP address, so my first question is where do I learn about property files, how do I access them, etc. My second question is about the user... I don't want the user to store id and password information on individual PCs. What I need help with is understanding the architecture involved in building a standalone Java app for JDBC. Here's what I had in mind. When a user opens the application, I'll have a log in screen which will create a User object. The user object then will get passed around throughout the application to provide this information. What I'm not sure about is the design itself: this would seem to mean a lot of Connections... is there a way to only create the connection once and then not close it until the user exits the application? Sorry if this is a little muddy but that's the way I feel about this project right now...at least I have 14 months to get it done! Thanks as always ------------------ I'm a soldier in the NetScape Wars... Joel

Wait a minute, I'm trying to think of something clever to say...<p>Joel

Originally posted by Joel Cochran:This is my first stab at JDBC. I've written a simple class that accesses our database and prints out a list of records from a file. In order to make it work, though, I had to hard code the IP address, the user name, and the user password. I've heard of something called a Property file that I could store the IP address in and retrieve it so that I could softcode the IP address, so my first question is where do I learn about property files, how do I access them, etc. what you can use is a ResourceBundle (java.util.ResourceBundle) it is rather simple to use: ResourceBundle rb = ResourceBundle.getBundle(myFile); String ip = rb.getString(myIpAdresse); ...... your file must be in the classpath

My second question is about the user... I don't want the user to store id and password information on individual PCs. What I need help with is understanding the architecture involved in building a standalone Java app for JDBC. Here's what I had in mind. When a user opens the application, I'll have a log in screen which will create a User object. The user object then will get passed around throughout the application to provide this information. What I'm not sure about is the design itself: this would seem to mean a lot of Connections... is there a way to only create the connection once and then not close it until the user exits the application? i do not know if it works in your case but you can keep your connection in the User Object you create ?? but be carrefull to close your connection at the End prehaps in the finalize method. I never use this kind of management because i have only one database user and i access my data by a connection pool... sorry if it doesn't help you Sorry if this is a little muddy but that's the way I feel about this project right now...at least I have 14 months to get it done! Thanks as always

------------------ Benjamin l�onard evisor

Joel Cochran
Ranch Hand

Joined: Mar 23, 2001
Posts: 301

posted May 16, 2001 09:09:00

0

Thanks Benjamin! Are the property files .ini files? .txt? I guess there is no reason not to have the connection as part of the user object, so that may solve my problem! Also, I've heard of connection pools, but I was under the impression they are just for JSP/Servlets...am I wrong? Thanks! ------------------ I'm a soldier in the NetScape Wars... Joel

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944

posted May 17, 2001 03:35:00

0

the properties files are simple text file we always used .properties but i don't know if it is mandatory inside properties are declare with = example

For connection pool it is mainly used in the server side application because it uses lots of connection at once. If the application is used by only one user at a time there is no reason to use a connection pool because only one connection is enough (prehaps in a singleton classes). But it to reply yes a connection pool can be used in a application.

There is a mechanism beyond the properties files : for the method getBundle(), you can pass two params. The first one is the resource name (ex. : "Preferences") The resource name could be also "com.mycompany.Preference". The second one (optional) is a Locale value (ex. : Locale.FRENCH) but in your case it's not usefull.ResourceBundle rb = ResourceBundle.getBundle("Preference", Locale.FRENCH); What will happen when you ask for a String or an Object with respectively rb.getString("key") or rb.getObject("key") ? If the default Locale is Locale.ENGLISH, the method will look in the classpath in the order that you put the different directories (ex:classpath=C:\program\lib;C:\program\bin\C:\program\res) I will search in the following order 1. C:\program\lib 2. C:\program\bin 3. C:\program\res for 1. a class called Preference_fr.class 2. a property file Preference_fr.properties 3. a class called Preference.class 4. a property file Preference.properties 5. a class called Preference_en_US.class 6. a property file Preference_en_US.properties 7. a class called Preference_en.class 8. a property file Preference_en.properties In case the search in a successfull loaded resource for the element "key" results in a fail, the search is made into the parent resource (with shroter name). If you use the properties file, be carefull with the characters =, space, :, newline, tab, return, they are used to mark the end of the key string and they must be escaped with \ and thus \ must also be escaped if they are used in the key String and in the value. = -> \= [space] -> \ (one space after \) : -> \: newline -> \n tab -> \t return -> \r \ -> \\ MyKey = My\ Value -> ("MyKey","My Value") My\ IP = 127.0.0.0\:8080 -> ("My IP", "127.0.0.0:8080") I hope this was not to confusing and helpfull. Laurent