I have a banking web application, the user fills out a registration form, presses register,
this takes them to RegistrationServlet which creates a 12-digit membershipNumber, which is stored in the servers MySql database.
Also an email is sent to the person registering giving them this membershipNumber.
The problem is the SQL query.. INSERT INTO... does not seem to work.
But I it did work the first time I ran it after I got my webhost to reload the war file.
I'm thinking it might have something to do with session, since it worked first time.
The two things:
1. creating session bean after user logs in (probably not this)
2. When I send email, I use
But I was using getDefaultInstance before, but I took it out for some reason.
My point is, I have no idea of whats going on, theres no output, I was thinking something about logging,
but I don't know how I can get this to work with my webhosting, I basically just upload a war file, then get it deployed/reloaded.
It works fine when I run the web app locally in netbeans 6.9, but problematic when I upload war file to server.
The thing is, I donno how to see the stack trace, its not running on my pc, so I was thinking about logging, but I'm confused how to set it up.
For the getInstance(), when I ran locally with getDefaultInstance() it was throwing an exception, something to do with the session.
But getInstance() seems to work fine on the server, it sends an email out every time.
Any thoughts? Thanks
Joined: Apr 11, 2005
I think I may have fixed it, will find out once my war file gets reloaded.
In my database utility class I had a static Connection member.
I was using the same thing for each query without resetting it or anything.
This probably explains why it only worked the first time it was called.
So now, for each query I just create a new connection, and run the query.
Question: I guess I should also close this connection object after I've processed the query?
Ok, but why always in a finally block?
Cause I have this code..
My point is that conn.close() may also throw an SQLException, so if you put it in a finally block,
you would need another try catch block. The current try catch catches the SQLException anyway,
so I don't see whats wrong with putting it where I have it.