Right now you’re probably asking yourself ‘’What happens
Right now you’re probably asking yourself ‘’What happens if the server crashes?” It’s a good question. The answer is that the destroy()method will not be called.** This doesn’t cause a problem for destroy() methods that only have to free resources; a rebooted server does that job just as well (if not better). But it does cause a problem for a servlet that needs to save its state in its destroy()method. For these servlets, the only guaranteed solution is to save state more often. A servlet may choose to save its state after handling each request, such as a “chess server” servlet should do, so that even if the server is restarted, the game can resume with the latest board position. Other servlets may need to save state only after some important value has changed a “shopping cart” servlet needs to save its state only when a customer adds or removes an item from her cart. Last, for some servlets, it’s fine to lose a bit of the recent state changes. These servlets can save state after some set number of requests. For example, in our InitDestroyCounterexample, it should be satisfactory to save state every 10 accesses. To implement this, we can add the following line at the end of doGet(): * The exact location of the current user directory can be found using System.getProperty( user.dir ). ** Unless you’re so unlucky that your server crashes while in the destroy()method. In that case, you may be left with a partially-written state file garbage written on top of your previous state. To be perfectly safe, a servlet should save its state to a temporary file and then copy that file on top of the official state file in one command. if (count % 10 == 0) saveState(); Does this addition make you cringe? It should. Think about synchronization issues. We’ve opened up the possibility for data loss if saveState()is executed by two threads at the same time and the possibility for saveState()not to be called at all if count is incremented by several threads in a row before the check. Note that this possibility did not exist when saveState()was called only from the destroy()method: the destroy()method is called just once per servlet instance. Now that saveState()is called in the doGet()method, however, we need to reconsider. If by some chance this servlet is accessed so frequently that it has more than 10 concurrently executing threads, it’s likely that two servlets (10 requests apart) will be in saveState()at the same time. This may result in a corrupted data file. It’s also possible the two threads will increment countbefore either thread notices it was time to call saveState(). The fix is easy: move the countcheck into the synchronized block where countis incremented: int local_count; synchronized(this) { local_count = ++count; if (count % 10 == 0) saveState(); } out.println(”Since loading, this servlet has been accessed ” + local_count + ” times.”); The moral of the story is harder: always be vigilant to protect servlet code from multithreaded access problems. Even though this series of counter examples demonstrates the servlet life cycle, the counters themselves aren’t particularly useful because they count only the number of times they themselves have been accessed. You can find two truly useful counters that count accesses to other pages in the next chapter. Single-Thread Model Although it is standard to have one servlet instance per registered servlet name, it is possible for a servlet to elect instead to have a pool of instances created for each of its names, all sharing the duty of handling requests. Such servlets indicate this desire by implementing the javax.servlet.SingleThreadModelinterface. This is an empty, tag interface that defines no methods or variables and serves only to flag the servlet as wanting the alternate life cycle.
Hint: If you are looking for very good and affordable webspace to host and run your java hosting application check Sandzak.com java web hosting provider