Some google and here you go http://www.trcinc.com/knowledge/articles.asp
Hava a nice day, xavier cosyns, Original Message ----------------------- The article is listed on the JavaReports website, but it is not published online (at least at JR's site). What's up with that? http://www.javareport.com/html/from_pages/author_index.asp#S Mark -----Original Message----- From: Sourabh Kulkarni [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 11:54 PM To: [EMAIL PROTECTED] Subject: Re: Connection in JSPs? can you send the url for the article? -sourabh ----- Original Message ----- From: ShriKant Vashishtha <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 01, 2002 9:50 AM Subject: Re: Connection in JSPs? > Hi All, > > I have found a very good article which does solve most of the problems > using design patterns. > The article "Applying Patterns to JDBC: Buiding a lightweight > Object-Relational Mapping > Framework" by Frank Sauer appeared in JavaReport magazine in May, 2001. > > Thanks all, > -ShriKant > > "A mailing list for discussion about Sun Microsystem's Java Servlet API > Technology." wrote: > > > Does somebody has some more clue about this issue....................... > > Please enlighten. > > > > -ShriKant > > > > "A mailing list for discussion about Sun Microsystem's Java Servlet API > > Technology." wrote: > > > > > First of all I want to clarify that I am not using entity beans to > access > > > database. I > > > appreciate your understanding about the usage of J2EE pattern. This > > pattern > > > is all about > > > resource independency, that means, after using that pattern, I need not > > > worry whether my > > > query is being processed by Oracle, Sybase, XML datastore etc. But I > > think > > > that is a separate > > > issue (resource independency). > > > > > > Here what I am worried of is, it may mean as many classes (read > > > implementation classes) as > > > there are tables and queries. It may become difficult to manage when we > > > have a large database > > > and schema. May be I am going to same line where you are. I want to put > > > that kind of > > > implementation in native SQL instead of Java classes. That means, there > > > should be some kind > > > of common interface which could interact with the query parameter, > query > > > identifier; and just > > > pass them to corresponding implemention of SQL. The interface should be > > > single controller to > > > manage it. I don't know how far is it possible. Any takers............ > > > > > > -ShriKant > > > > > > "A mailing list for discussion about Sun Microsystem's Java Servlet API > > > Technology." wrote: > > > > > > > Well. It all depends on how you access the DB whether thru Entity > > beans, > > > > direct Sql drivers etc., As you might know there is a j2ee pattern > > called > > > > "Data Access Objects(DAOs)" using which you can do these. It's > nothing > > > but > > > > kind of using the power of interfaces in Java. For example, you can > > > declare > > > > an interface with business methods. Let's say you need to access a > user > > > > table. Then you may have, > > > > > > > > public interface DBAccess{ > > > > public void addUser(UserInfo ui) throws SQLException; > > > > public void deleteUser(String userId)throws SQLException; > > > > public void modifyUser(UserInfo modifiedUser)throws SQLException; > > > > public UserInfo getUser(String userId) throws SQLException; > > > > public void getUsers()throws SQLException; > > > > } > > > > > > > > You can write implementaion classes for this interface depends on the > > > > Database you use. The code to add/modify/delete data into/from a > > database > > > > will reside in a single place(implementation classes) which will lead > > you > > > > to a better maintainalbe code. > > > > > > > > For example, you may use a RDBMS, ordinary DBMS even flat files. As > > long > > > as > > > > your code talks to an interface, you can plug in the implementations. > > > > > > > > For example you use two kinds of DBs in your code. Then, > > > > DBAccess db = DBAccessFactory.getInstance("Oracle"); > > > > UserInfo ui = db.getUser("shri"); > > > > db.deleteUser("shri"); > > > > db = DBAccessFactory.getInstance("SQLServer"); > > > > db.addUser(ui); > > > > > > > > So even if you change the implementation classes, your code still > > works. > > > > I don't prefer going for stored procedures and writing methods which > > > takes > > > > a Query as an argument. If you want this only, then that is what your > > > > statement/prepared statements do. > > > > > > > > -----Original Message----- > > > > From: ShriKant Vashishtha [mailto:[EMAIL PROTECTED]] > > > > Sent: Monday, January 28, 2002 5:37 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: Connection in JSPs? > > > > > > > > Is there a generic approach/pattern/framework by which we just need > to > > > > specify the query > > > > parameter and that will give us the respective response. I want to > use > > a > > > > common interface > > > > (and put it into a Class) for all the sql ueries for all the JSP > which > > > > should not be > > > > dependent upon the query parameter and type of query. One possible > > > solution > > > > I can think of to > > > > use the stored procedure for all JDBC related work and pass them the > > > > necessary parameters > > > > required and get the response in return. But at present I am not very > > > sure > > > > of the pros and > > > > cons of this strategy. Is there any other possible solution. Please > > > > enlighten........... > > > > > > > > -ShriKant > > > > > > > > "A mailing list for discussion about Sun Microsystem's Java Servlet > API > > > > Technology." wrote: > > > > > > > > > You can write an utility class kind of thing like > ConnectionPool.java > > > > which > > > > > has methods like public Connection getFreeConnection() and public > > void > > > > > returnConnection(Connection c). > > > > > Make sure that you don't close the connections in your JSPs after > > use. > > > > Let > > > > > the same utility class close the connections when it decides they > are > > > not > > > > > necessary. > > > > > So that you can have the code two aquire a DB connection in one > > place > > > > > which will be easier when you might change the server/driver etc in > > > > future. > > > > > -----Original Message----- > > > > > From: Sumit Mishra [mailto:[EMAIL PROTECTED]] > > > > > Sent: Monday, January 28, 2002 10:31 AM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Connection in JSPs? > > > > > > > > > > Hi, > > > > > > > > > > What can be the best way of taking connection in a JSP when u have > to > > > > fire > > > > > a query in almost every JSP? Is the useBean approach ok?? > > > > > > > > > > Regards, > > > > > Sumit > > > > > > > > > > > > > > ___________________________________________________________________________ > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in > the > > > body > > > > of the message "signoff SERVLET-INTEREST". > > > > > > > > Archives: http://archives.java.sun.com/archives/servlet-interest.html > > > > Resources: > http://java.sun.com/products/servlet/external-resources.html > > > > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html > > > > > > > > > ___________________________________________________________________________ > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > > body > > > of the message "signoff SERVLET-INTEREST". > > > > > > Archives: http://archives.java.sun.com/archives/servlet-interest.html > > > Resources: http://java.sun.com/products/servlet/external-resources.html > > > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html > > > > > ___________________________________________________________________________ > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > body > > of the message "signoff SERVLET-INTEREST". > > > > Archives: http://archives.java.sun.com/archives/servlet-interest.html > > Resources: http://java.sun.com/products/servlet/external-resources.html > > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html > > ___________________________________________________________________________ > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff SERVLET-INTEREST". > > Archives: http://archives.java.sun.com/archives/servlet-interest.html > Resources: http://java.sun.com/products/servlet/external-resources.html > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html > ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
