Another point is that in this singleton class you can populate the data from the resultset object into a DTO and just return it to the calling class and then close the connection.
Thus all database access and pooling is restricted to this singleton class. This resolves the overhead of maintaining the connection and frees up the conn into the pool. This design works for us. But still depends a lot upon the pattern and design of the project in question. HTH, uthiresh -----Original Message----- From: A mailing list for discussion about Sun Microsystem's Java Servlet API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of Ranjith Chakravarthi Sent: Friday, January 31, 2003 10:44 AM To: [EMAIL PROTECTED] Subject: Re: odd oracle error [MAX cursors] i was wondering how VIKRAM who has done just that is not speaking up and is saying something else. this is the BEST way as far as i know. ADVANTAGES 1)encapsulation of code 2)debugging ease 3)optimized functioning of database calls 4)simple code in front end code making it easy to code and maintain. -----Original Message----- From: Uthiresh Narayanan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 4:20 AM To: [EMAIL PROTECTED] Subject: Re: odd oracle error [MAX cursors] another way is to encapsulate all the database access and iteration code into one singleton class and handle all the logic there, instead of scattering the code in all classes It helps in maintainabilty also.... cheers, uthiresh -----Original Message----- From: A mailing list for discussion about Sun Microsystem's Java Servlet API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of Thiharie Rajesh Sent: Wednesday, January 29, 2003 5:15 PM To: [EMAIL PROTECTED] Subject: Re: odd oracle error [MAX cursors] Very sensible indeed. We learnt this the hard way during load / stress testing. -----Original Message----- We used to get this too and fixed it by making sure that any Statements and ResultSets we create are explicitly closed in finally blocks. It appears that these objects hold a cursor open while they live (one or the other or both, not too sure so I manage both). What we now do in fact is manage them as rigorously as we do transactions and anywhere we create either, we immediately start a "try" block and ensure that the they are closed in the "finally" - this required a bit re-architecting to ensure that all the "close" calls could be done in the same block of code. ____________________________________________________________________________ ________________________ This email and any attached to it are confidential and intended only for the individual or entity to which it is addressed. If you are not the intended recipient, please let us know by telephoning or emailing the sender. You should also delete the email and any attachment from your systems and should not copy the email or any attachment or disclose their content to any other person or entity. The views expressed here are not necessarily those of Churchill Insurance Group plc or its affiliates or subsidiaries. Thank you. Churchill Insurance Group plc. Company Registration Number - 2280426. England. Registered Office: Churchill Court, Westmoreland Road, Bromley, Kent BR1 1DP. ___________________________________________________________________________ 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 Disclaimer: This e-mail message along with any attachments is intended only for the addressee and may contain confidential and privileged information of GTL Limited. If the reader of this message is not the intended recipient, you are notified that any dissemination, distribution or copy of this communication is strictly prohibited. If you have received this message by error, please notify us immediately, return the original mail to the sender and delete the message from your system. ___________________________________________________________________________ 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
