• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Javabeans and socket error?

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am the first in our office to implement javabeans into a project. Normally we just access the database, store in variables and pass either in hidden fields or in the URL to the next page. Now I am having major issues and I need to know if it is the beans causing my problems.

Pages that loaded correctly are now not loading correctly. There are too many instances to go into but the pages just don't display well. Though some will if they are refreshed. If there was a problem with my code would it not display at all everytime I get the page instead of clearing up when refreshed? Or loading sometimes but not others? (and I mean with a 10 minute period).

I was demoing the project this morning, there was nothing wrong. It ran perfectly. Then all of a sudden pages that were displaying properly wouldn't display anymore. We demoed for over an hour before it crapped out. I don't think its the code because if there was a problem with it I would have gotten these errors on my machine (we were demoing on the boss' machine in another room). He thinks the problem is the javabeans.

Tomcat is giving me the error:
[Microsoft][SQLServer 2000 Driver for JDBC]Connection reset by peer: socket write error

I know this isn't the sql forum but what I need to know is if javabeans can give me this error? Can they cause any errors that I might not be familiar with? Should I switch back to using request.getParameter to pass all data? I need to have a finished demo on Tuesday so I need to know fast if I need to convert all the beans over to the old request.getParameter style?
 
Ranch Hand
Posts: 823
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Linda,

Welcome to the Ranch.

JavaBeans are usually fairly innocuous little classes which wouldn't dream of harming a server or a page. It's very hard to say with so little information but I'd be surprised if the Beans were the direct cause.

I would say that the most likely cause of your display problems is your boss's caching settings in Internet Explorer. Under Tools => Internet Options => Temporary Internet Files => Settings, ensure that neither of the "Every time" options is selected.

Your SQL Server error is caused when the connection to the DB is lost. Maybe your friendly DBA dropping your session due to a rogue query, or perhaps something more sinister...

Of course your problems could be caused by recent changes to your code, so if my suggestions don't help you need to track back through what you've done recently to see what your changes might have broken.

Hope this helps.

Jules
 
Linda Thomas
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the welcome I've surfed around here a bit but haven't participated up til now.

Well the set up we have for projects is that the students (I myself being one) code the JSP pages. The webmaster has made 3 class files: ConnectionPool.java, PooledConnection.java and Connection.java. These 3 classes work to create the connection to the database.

We have sort of a base template we use for our projects. Like News program had New.java. It creates a vector ResultSet and an Object ResultSet then has an execute ("public void execute( HttpServletRequest request,HttpServletResponse response, ServletContext context ) throws Exception"). Inside here is:
// Get a database connection from connection pool -- POOL
ConnectionPool pool = ( ConnectionPool )context.getAttribute( "POOL" );
Connection con = pool.getConnection();

// create HTTP session
HttpSession session = request.getSession();

After this we have a try and catch set up. Within the try is where we students work. The rest of the code is all set up and we just copy an old file and alter the try. Within here we request a mode from our page and then we test for it. So my project has if (mode.equals(addclient)).

Within the if/else if statments we can create a CallableStatement if we have a stored procedure or we use a Statement until the stored procedure can be created for us. It is pretty simple for us to create a project but we have no real idea what's going on in the java files he's made to see if the connections are all being closed properly.

One thing we do though is if we produce a listbox, we make a seperate .jsp page and connect through there. The webmaster came to us a couple months back and told us to make sure we were closing everything off properly, that some sockets or connections weren't closing properly. There is a language barrier and its very difficult to get some standards set up because he seems to change his mind with different students and different projects (like one guy now is not using those 3 java connection files, he's doing all his connections directly with no stored procedures). But I want to be sure I'm closing everything so I want to check here, which of these need to be manually closed?

ResultSet rs with rs.close();
Statement stmt with stmt.close();
CallableStatement cstmt with cstmt.close();

We do the first two but I am wondering if we need to close the CallableStatement (which I have never done or seen done in any of our projects).

In my beans I am only importing the following:

package edu.admin.services;

import java.sql.*;
import java.util.*;
import java.lang.*;

There is no direct connection to the database, nothing to do with the database at all. All it is is properties with gets and sets, one that reinitializes everything to 0 or "" and one that takes the object search_results generated from the database class file (Clients.java, News.java, PhoneBook.java, etc) and sets all the properties.

Now in my Clients.java file I am importing import edu.admin.services.ClientBean;
and using ClientBean newBean = ( ClientBean )session.getAttribute( "clientbean" ); to access the information I have stored in my bean, could this be a problem?

Honestly I love working with the beans. My clients have close to 50 properties that are viewed and updated across multiple pages within my project. We have had problems with special characters being passed between pages, especially through URLs, and to the database. We've had to create huge functions to replace any special character we can think of, resorting to replacing & with AMP; and other ugly messy handling functions. When looking into the database if we didn't use these functions all the special characters were stored as ? but the database took the special characters in a bean and saved em just like they were, ie @#$%^&*!. No problem.

I am very reluctant to remove the beans. I've been able to take 6 pages of code to add a client and reduce it to 3. I've been able to seperate interface from business logic. There is no way I could explain that to my supervisor in a way he would understand. But since I'm the only one in the office who's ever worked with beans I have no clue as to some of the issues that they can cause in development.

Are there any problems with beans? Are they less reliable than session variables? Is there a way they can easily lose their information? My user logins in and creates a bean and if the bean dies in the middle of the program the user's screwed and so am I. Is there anything to do with beans that I am unaware of?

P.S. Thanks for replying Jules! It was terribly frustrating today when we demo'd for over an hour with my code working perfectly before socket errors made it crap out. Then the guy says its my code but it was fine and we saw those pages load within the that demo. He said my code is unreliable and he blames the beans yet I brought him 6 pages of tomcat screenshots showing him the socket errors. He still thinks its my code
 
Linda Thomas
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My javabeans are set to session scope, should they be set to application scope? I tried that but when I tried to do ClientBean newBean = ( ClientBean )session.getAttribute( "clientbean" ); I would get an error. Should it be application.getAttribute? I think I tried that and it didnt' work either.
 
JulianInactive KennedyInactive
Ranch Hand
Posts: 823
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Whoa! That's a bit of an essay, but I suppose I asked for it.

OK, where to start? Firstly it looks to me that you're doing more or less everything right and using what I understand to be best practice (or at least standard practice) for servlet-based web apps.


which of these need to be manually closed?

ResultSet rs with rs.close();
Statement stmt with stmt.close();
CallableStatement cstmt with cstmt.close();


OK, the rule here is to close everything you open/create once you've finished with it, so yes, you need to close CallableStatements. I'm not sure it'll make any difference here as the unclosed CS will just be garbage collected once out of scope but it's good practice anyway.


In my beans I am only importing the following:

import java.sql.*;
import java.util.*;
import java.lang.*;


You don't need to import java.lang. It's always available to you.


Are there any problems with beans?
Are they less reliable than session variables?
Is there a way they can easily lose their information?


OK, one at a time! The way you're using them:
  • there are no problems with beans that I am aware of.
  • they are session variables, just more complex ones (same as any object assigned to a variable in a Java program)
  • not unless you do something in your code to reset it



  • My javabeans are set to session scope, should they be set to application scope?


    Your beans are only relevant within a given session - they don't need to be visible to other sessions (that would be bad!). They're set up right as they are.

    You don't do anything daft like storing the DB connection in the session context, do you? In a typical pooled connection implementation the connections expire and are replaced after a given period. If you're holding on to one for a long time, that could cause your symptoms, i.e. works fine for an hour and then goes pear-shaped as the pool drops the expired connection. You should also be returning the connection to the pool at the end of your processing (not closing it, just returning it to make it available to another session). The connection pool is in the ServletContext (app context) so it's available to everyone. Can you see the difference between that kind of resource, which belongs at the application level, and your bean?

    I think that's answered all your questions. I hope it helps to clear up your problem.

    I sympathise with you regarding your supervisor. You do appear to be using best practice and, though it probably is your code at fault, I'm pretty confident it's not your beans.

    Jules
     
    Linda Thomas
    Greenhorn
    Posts: 8
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks for replying!! I feel so much better!

    There was definitely a learning curve and I know this project has been delayed as a result of me incorporating the beans but I have always felt that the effort was worth it. I have been coming in weekends and nights and even working on code at home because I felt so strongly about it. Then he critisized the code yesterday and I dropped rock bottom and came in today not caring about the project.

    I do believe it has to do with code as well but not the beans. I think it has something to do with the connections. I looked and the connections are being released rather than closed.
    finally
    {
    try
    {
    pool.releaseConnection( con );// release the connection
    } catch( Exception ce )
    {
    System.err.println( "Connection Release Exception: " + ce.getMessage( ) );
    }
    }

    When the new guy started he remembers, as do I, the webmaster coming in complaining that connections weren't being properly closed, related to result sets and statements, and stressed the importance of us closing all down when we are finished.

    What I am wondering is, the CallableStatments (cstmt) are used throughout all of our programs. We have about 10-12 programs that can be accessed at anytime by those authorized to do so. The folder structure is webapps/name/ where name is whatever directory he's using at the time (we have 3 main areas where a program can be placed on server and we recreate the structure on our C drive.

    Under name is admin (for administrative sides to a program), web for public side of a program, source where our .java files are and WEB-INF for where our compiled classes go.

    Under the source its source/edu/name/ then admin, web, connectionpool, util and control. So every admin and web program is using the same connectionpool files. I was wondering if there might be an accumulative effect of multiple programs trying to access the same connection files? For me running on my standalone machine its not a problem but the live programs may have multiple users accessing multiple programs. Since I am running standalone do standalone programs and live programs have an accumulative effect on the server? Its all going to the same server. Is this a possibility?

    Thanks again for replying! I feel so much better! This is the second solo project I've done and I look back at my first one and think how much more efficient and elegant I could have made the code and I really wanted to do this one proud!
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic