Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Threads for asynchronous tasks  RSS feed

 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am creating a JSP application, running on Tomcat 4, which comprises fairly simple JSP code making calls to fairly complex Java libraries in JARs in WEB-INF/lib. It also makes slight use of a mySQL database instance.
Questions:
1) Is it allowed or advisable to create threads in the library code, to do asynchronous tasks like lazy update? Or will this break Tomcat?
2) What alternative strategies exist for asynchronous tasks?
I ask, because my libraries, not particularly coded to work with Tomcat, make use of background threads. All seems to work great on my development Web server, but some of the application's pages seem to get "wedged" and never display on the production Web server.
 
Shawn Bayern
Author
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peter Chase:

1) Is it allowed or advisable to create threads in the library code, to do asynchronous tasks like lazy update? Or will this break Tomcat?

Interesting questions! It's allowed; JSP doesn't really care what your back-end libraries do. Whether they're multi-threaded or not is something of an implementation detail. (For instance, I described in an article a year or so ago in Dr. Dobbs how using multiple threads with recursion is a convenient way to acquire a sensible Iterator from an algorithm that's most naturally expressed recursively. The point is, the fact that the library uses two threads is an implementation detail; nobody else needs even to know that the extra threads are present.)
Whether or not it's advisable is up to the libraries you're using. Introducing threading can complicate the library and your JSP pages. Keep in mind a few things: if your library isn't re-entrant (that is, if it can't be called multiple times before the first invocation breaks), it will probably break if called directly from a JSP page because multiple pages might be started nearly simultaneously, in response to HTTP requests. Similarly, imagine your library produces ten threads; if you get 50 requests, you suddely have 500 threads, which is somewhat burdensome even on a good JVM. On most systems, you'll run out of memory before 1000 threads
Originally posted by Peter Chase:

2) What alternative strategies exist for asynchronous tasks?

Unfortunately, I'm not sure I understand the scope of the question. In principle, though, you have two different kinds of strategies available: you can either (a) spawn threads and wait for them to return, committing your response only once your work is done; (b) spawn threads and return immediately, treating the threads as "batch processing."
Originally posted by Peter Chase:

I ask, because my libraries, not particularly coded to work with Tomcat, make use of background threads. All seems to work great on my development Web server, but some of the application's pages seem to get "wedged" and never display on the production Web server.

It's hard to debug a problem like this with only that level of detail. There could be a number of issues -- security managers on the production server, for instance. But in principle, I don't know of any reason why it shouldn't work, short of the caveats I've mentioned here.
Hope that helps in some way.
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I am actually doing is as follows.
My JSPs update data that should be persisted in the database. However, that doesn't need to happen immediately and my world wouldn't end if a database update occasionally failed to happen.
So, rather than make the page wait for the database, I have a lazy update thread. There is one such thread in the page (its object reference is a page-scope variable). Most of the time, it's in wait(), synchronised on the lazy-update thread instance, but individual sessions may notify() it (again synchronised on the lazy-update thread instance) to tell it that there's new data to be written (the data is in-memory at that time). Then, while synchronised on the lazy-update thread instance, it writes the data to the database.
As the lazy-update thread holds the lock on itself all the time except when it's waiting, it shouldn't be possible for a notify() to occur at an inappropriate time.
In case this wasn't taxing enough, I thought I'd pool my database connections. Another thread is running to scavenge spare connections.
 
Shawn Bayern
Author
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peter Chase:
So, rather than make the page wait for the database, I have a lazy update thread. There is one such thread in the page (its object reference is a page-scope variable). Most of the time, it's in wait(), synchronised on the lazy-update thread instance, but individual sessions may notify() it (again synchronised on the lazy-update thread instance) to tell it that there's new data to be written (the data is in-memory at that time). Then, while synchronised on the lazy-update thread instance, it writes the data to the database.
As the lazy-update thread holds the lock on itself all the time except when it's waiting, it shouldn't be possible for a notify() to occur at an inappropriate time.

Hi again, Peter. It's still hard to say why your code is failing in one environment but not another. However, as a general point of design, why cause JSP pages to block behind a busy thread? Instead, why not have them write their data to a synchronized queue (e.g., a Vector, or more appropriately, these days, a synchronized ArrayList) and notify() only to wake a sleeping thread. The lazy thread then does:

If your code is deadlocking, this might alleviate the problem.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!