N Carlo

OK, sounds like using local variables is the standard way to do it, so I'll go that route. Thanks for your help.

Hi James,

Thanks for your reply. Can you explain the reason why they should be local variables? What is the danger of putting them in the base class?

Hi all,

In my web application, I have a base class called Dao that contains the following:

protected Connection conn = null; protected PreparedStatement stmt = null; protected ResultSet rs = null; public Connection getConnection() { ... }

Then I have subclasses that extend Dao and inherit the Connection, PreparedStatement, and ResultSet. Here is an example of how they are used:

String sql = "SELECT * FROM SOME_TABLE"; conn = getConnection(); stmt = conn.prepareStatement(sql); rs = stmt.executeQuery(); ...

The reason for doing this is simply that the subclasses always need those variables to do their work, so it seemed sensible to put them in a parent class. Is there any risk or drawback to doing it this way? Is it better to just always declare the Connection, PreparedStatement, and ResultSet as local variables? Thanks for your help.

Thanks Bear!

Hi Bill,

Thanks for your reply. If you store session data in the database, don't you need a way to clear it out when the user's session ends? Would you run a job daily to clear out everything older than 24 hours, or something like that?

Hello all,

I am developing a web application where if the user's session times out, the next time he clicks on a link, he is redirected to the login page. After he logs in again, he is then taken to the page he was trying to access. The trouble is, I am storing some information in the session scope. For example, the user can view all the items he has created in the application. I store this list in the session. Now, suppose the user tries to view one of those items, but his session has timed out. So, he logs in again, but now his old session variables are gone, so when the login page forwards him to the page that should display the item details, the list is null, and I end up with a stack trace on the screen. What is the best way to handle this situation? Thank you for your help.

Thanks, Sarvesh. After looking into it some more, I realized that the main application was (sometimes) terminating before the threads could complete their work. I added a call to Thread.join() so the main application waits for the threads to complete before exiting, and now it works fine. Thanks again for your help.

Thanks, Paul. I will look more closely at that.

Hello all,

My program works fine without concurrency, but when I introduce threads, it sometimes fails to produce any output. The code looks like this:

public abstract class Engine implements IEngine { // IEngine has a turnOn() method public void ignition() throws Exception { String concurrent = properties.getProperty("concurrent"); if (concurrent != null && concurrent.equals("true")) { Thread t = new Thread(new Starter()); t.start(); } else turnOn(); } private class Starter implements Runnable { public void run() { turnOn(); } } }

Note that the abstract base class Engine does not implement the turnOn method. Its concrete subclasses, such as CarEngine and TruckEngine do. It seems to me that the inner class Starter should call the outer class's turnOn method, which is implemented by the concrete subclasses, but again, sometimes it works and sometimes nothing happens. When it fails, I do not get an exception, I just get no output. What is going on here? Any and all help is greatly appreciated.

One thing I am not clear on is how to use a transaction to prevent this race condition. My understanding is that a transaction will lock the row for writing, but not for reading. So, how do I prevent Thread 2 from reading the value before Thread 1 updates it? Any code samples of how to prevent this with a transaction would be greatly appreciated. I also tried using SELECT FOR UPDATE but I still get the race condition. Here is some code to illustrate my current approach, which is not working. I'm not sure if I need to roll back on line 30, but I wanted to make sure that nothing would stay locked.

// Get a database connection. conn = getConnection(); // Begin the transaction. conn.setAutoCommit(false); // Get the current value. sql = "SELECT FLAG FROM JOBS WHERE ID='" + id + "' FOR UPDATE"; stmt = conn.prepareStatement(sql); rs = stmt.executeQuery(); // Read the value. if (rs.next()) { String value = rs.getString(1); if (value.equals("N")) { sql = "UPDATE JOBS SET FLAG='Y' WHERE ID='" + id + "'"; stmt.close(); stmt = conn.prepareStatement(sql); stmt.executeUpdate(); conn.commit(); } } else { // No value found. conn.rollback(); }

Hi all,

I am having trouble preventing a race condition in a J2EE app that accesses an Oracle database. The sequence of events goes like this:

1) My servlet receives a request.
2) The servlet checks the value of a flag stored in the database.
3) If the flag is set to 'N' then it sets it to 'Y', and performs some other actions that must only be done once.

The problem occurs when I have multiple simultaneous requests (which is common for this particular service). For example:

Thread 1 checks the flag and sees that it is N.
Thread 2 checks the flag and sees that it is N.

Thread 1 updates the flag to Y and does the stuff that should only be done once.
Thread 2 also updates the flag to Y and proceeds to duplicate the work that should only be done once.

What I want is to prevent Thread 2 from reading the flag until after Thread 1 has had a chance to update it. What is the best way to do this in JDBC? I thought about using transactions, but I wasn't sure if that would provide the intended functionality. Any and all help is greatly appreciated.

Hi Paul,

Thanks for your response. After some further reading on this subject, I realized that while waitFor is OK to use in a servlet, it does have some pitfalls, which I am now accounting for. For example, I don't think my external process will produce any console output, but now I make sure to consume any such output as a precaution to keep the process from blocking. I also spent some time monitoring the resource consumption by the external process while it was running, and realized that it was eating up a lot of memory on the application server. I think that's probably what led to the performance degradation I witnessed.

You are correct, that a servlet should never take that long to respond. I should have clarified that in my case, the servlet responds right away before running the external process, so the client immediately gets an acknowledgment that the request was received and is being processed.

Thanks!

Hi all,

I am currently developing a servlet to be integrated with a third-party application. At one point, my servlet instantiates a class that calls an external application using Runtime.exec(). Then it calls Process.waitFor() to wait for the external process to complete.

For large input files, this external process can take as much as ten minutes to run. During that time, the entire web application becomes unresponsive, even the parts that have nothing to do with my servlet. The web application slows to a crawl until the external process completes and waitFor() returns. I am trying to determine the reason for this behavior.

While it is possible that the delay is caused by the external process using too much memory and/or CPU time, I just want to know if it is generally a bad idea to call Process.waitFor() from a servlet (or from another class that is instantiated by the servlet). Will that in itself cause the entire web application to hang? Note that the external process being called is a native application, not a Java app.

Thanks in advance, any and all help is greatly appreciated.