Hi Jonathan,
THe biggest problem with storing Connections in the Servlet is that
the Connection objects are not serializable, so when the Servlet Engine will
start serializing the HttpSession and it does that when transferring load,
or some instance of this type then it will throw NotSerializableException
for the Connection object because it tries to serialize whatever is sored in
the Session.
Also Servlet API 2 spec state that any object which is being strored
int the session should be serializable ,and in this case the behavior of the
Servlet Engine is not fixed, not fixed in the sense that some Servlets
Engine like JRUN restarts itself( Ouch.. ), about others i don'e have idea
what they do you will have to go through their documentations.
So in my advice you use a connectin pool and do not store the
Connection objects in the Session. The Jason Hunter book has an example of
Pooling you can modify it according to your needs and use it, it is one day
job at the max, i think.
May the Force be with you
> -----Original Message-----
> From: Jonathan Silvergran, SM3OJR [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, January 05, 2001 7:41 PM
> To: [EMAIL PROTECTED]
> Subject: Connections bound to the session - comments wanted
>
> Greetings,
>
> In a web ap consisting of a number of servlets, I have a "WelcomeServlet"
> which is the first servlet called for each session. In this servlet, I
> create a JDBC connection that I store in the session.
>
> I have created a method for executing SELECT queries that looks like this:
>
> // Set autoCommit to false in the query call for manual transactions
> public ResultSet runQuery(boolean autoCommit, String qString) {
>
> Connection con = (Connection)session.getValue("connection"); // Get the
> conn from session
>
> try {
>
> if ( con != null ) {
>
> if ( !autoCommit )
> con.setAutoCommit(false);
> else
> con.setAutoCommit(true);
>
> Statement statement = con.createStatement();
> rs = statement.executeQuery(qString);
>
> session.putValue("connection", con); // Write the conn back to the
> session in
> // case the AutoCommit status
> has changed
> }
>
> catch... etc
>
> return rs // returns the ResultSet
> }
>
>
> First, is this way of handling connections recommendable? My application
> will not be used by that many, especially not at the same time. I know
> that a ConnectionPool is more appropriate, but I don't have the time to
> learn how to do it. (The Hunter's servlet book said it was fairly
> complicated.. :)
>
> Second, I have a problem with the AutoCommit setting. If I don't touch it
> at all (ie remarking the if clause in the code above) it works great. On
> the other hand, if I put setAutoCommit(true) and try to execute a query,
> an empty ResultSet is returned. Why? I can't see the differenct between
> turning AutoCommit on and doing nothing at all, which, AFAIK, actually IS
> AutoCommit on...
>
> Any comments appreciated. Thanks!
>
> /Jon
> Jon, sm3ojr
>
> European distributor of the following products:
>
> * TR Logging Program (by N6TR)
> * WJ2O Master QSO Logging Program (by WJ2O)
> * RTTY (by WF1B)
>
> ---
> Jonit Software, Box 178, SE-83122 OSTERSUND, Sweden
> Phone: +46-63-57 21 21
> Fax / 24h order: +46-63-57 21 22
> Mobile: +46-70-569 21 21
> E-mail: [EMAIL PROTECTED]
> URL: http://www.jonit.com
> ICQ: 7319834
> ---
>
> __________________________________________________________________________
> _
> 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
