3

I have a local web app that is installed on a desktop PC, and it needs to regularly sync with a remote server through web services.

I have a "transactions" table that stores transactions that have been processed locally and need to be sent to the remote server, and this table also contains transactions that have retrieved from the remote server (that have been processed remotely) and need to be peformed locally (they have been retrieved using a web service call)... The transactions are performed in time order to ensure they are processed in the right order.

An example of the type of transactions are "loans" and "returns" of items from a store, for example a video rental store. For example something may have been loaned locally and returned remotely or vice versa, or any sequence of loan/return events.

There is also other information that is retrieved from the remote server to update the local records.

When the user performs the tasks locally, I update the local db in real time and add the transaction to the table for background processing with the remote server.

What is the best approach for processing the background tasks. I have tried using a Thread that is created in a HTTPSessionListener, and using interrupt() when the session is removed, but I don't think that this is the safest approach. I have also tried using a session attribute as a locking mechanisim, but this also isn't the best approach.

I was also wondering how you know when a thread has completed it's run, as to avoid lunching another thread at the same time. Or whether a thread has ditched before completing.

I have come accross another suggestion, using the Quartz scheduler, I haven't read up on this approach in detail yet. I am going to puchase a copy of Java Concurrency in Practice, but I wanted some help with ideas for the best approach before I get stuck into it.

BTW I'm not using a web app framework.

Thanks.

GreensTuf
  • 41
  • 4

2 Answers2

3

Safest would be to create an applicationwide threadpool which is managed by the container. How to do that depends on the container used. If your container doesn't support it (e.g. Tomcat) or you want to be container-independent, then the basic approach would be to implement ServletContextListener, create the threadpool with help of Java 1.5 provided ExecutorService API on startup and kill the threadpool on shutdown. If you aren't on Java 1.5 yet or want more abstraction, then you can also use Spring's TaskExecutor

There was ever a Java EE proposal about concurrency utilities, but it has not yet made it into Java EE 6.

Related questions:

Community
  • 1
  • 1
BalusC
  • 992,635
  • 352
  • 3,478
  • 3,452
  • if we use ExecutorService - how is the thread pool "managed by the container"? That is exactly what I am looking for - a way to make Tomcat manage my worker threads for me. – bloodcell Apr 11 '11 at 14:11
  • @bloodcell: Sorry, my answer was a little unclear. I didn't mean that "the basic approach" is the same as using a container managed threadpool. I've updated the answer. Tomcat does by the way not support it out the box, so you have to create/manage it yourself or to use 3rd party API like Quartz/Spring. – BalusC Apr 11 '11 at 14:21
  • thanks :) I have an overlapping open question explaining my scenario here - http://stackoverflow.com/questions/5612574/server-side-performing-multiple-requests-against-cloud-services – bloodcell Apr 11 '11 at 14:57
1

Its better to go with Quartz Scheduling framework, because it has most of the features related to scheduling. It has facility to store jobs in Database, Concurrency handling,etc..

Please try this solution

  1. Create a table,which stores some flag like 'Y' or 'N' mapped to some identifiable field with default value as 'N'
  2. Schedule a job for each return while giving loand it self,which executes if flag is 'Y'
  3. On returning change the flag to 'N',which then fires the process which you wanted to do
Ratna Dinakar
  • 1,563
  • 13
  • 16