CODEWITHSUNDEEP
javamultithreadingconcurrency
Piotr Müller
Piotr Müller

Reputation: 5548

Lightweight long-running method cancel pattern for Java

Is there a lightweight pattern to cancel long running method, which replaces code like this:

public void longComputations() {
   ... first step...
   if ( cancelled ) {
      rollbackWork();
      return;
   }
   ... second step...
   if ( cancelled ) {
      rollbackWork();
      return;
   }
   ... third step...
   if ( cancelled ) {
      rollbackWork();
      return;
  }
}

I know that I can make a Task class, subdivide steps to task objects, make a queue and just do tasks step by steps in loop with cancelation checking, but I'm just wondering is there any simple code-structure pattern for such situation.

Upvotes: 5

Views: 822

Answers (4)

Andrey Chaschev
Andrey Chaschev

Reputation: 16496

How about this edit, not a pattern though? Exceptions are very cheap, so it should be fast.

public void caller(){
    try{
        longComputations();
    } catch (MeaningfulRuntimeException e){
        rollbackWork(e.getStep());
    }
}

public void longComputations() {
   ... first step...
   checkStatus(1);

   ... second step...
   checkStatus(2);

   ... third step...
   checkStatus(3);
}

public void checkStatus(int step){
    if ( cancelled ) {
        ... we may rollback here or throw an exception ...
        throw MeaningfulRuntimeException(step);
    }
}

Upvotes: 2

halfbit
halfbit

Reputation: 3464

You might want to consider using the java.util.concurrent package. You need to wrap your working steps as Callables (or Runnables).

public class InterruptibleTest {
    public static void main(String[] args) { try {
        final ExecutorService queue = Executors.newFixedThreadPool(1);
        queue.submit(new Callable<Void>() { @Override public Void call() { busyWait(1000); return null; } });
        queue.submit(new Callable<Void>() { @Override public Void call() { busyWait(1000); return null; } });
        queue.submit(new Callable<Void>() { @Override public Void call() { busyWait(1000); return null; } });
        final AtomicBoolean cancelled = new AtomicBoolean();
        new Thread() { @Override public void run() {
                try { Thread.sleep(1500); } catch (InterruptedException ex) { }
                queue.shutdownNow();
                cancelled.set(true);
            }
        }.run();
        if (cancelled.get()) { rollback(); }
        queue.shutdown();
        System.out.println("Finished");
    } catch (Exception ex) { ex.printStackTrace(System.err); } }

    public synchronized static void busyWait(int millis) {
        System.out.println("Start");
        long until = System.currentTimeMillis() + millis;
        while (System.currentTimeMillis() < until) { }
        System.out.println("Stopped");
    }
    public synchronized static void rollback() {
        System.out.println("Rollback!");
    }
}

Note that shutdownNow() might call interrupt() on the currently executing work thread. You will probably also need to synchronize your rollback() because shutdownNow() returns before non-interruptible code finishes execution.

Upvotes: 0

Adam Zalcman
Adam Zalcman

Reputation: 27233

If the steps call methods which throw InterruptedException then you can use Thread.interrupt(). You will still need to maintain enough state information to do the rollback properly.

If the steps cannot be interrupted this way, you should not consider relying on the deprecated Thread.stop() mechanism since it is inherently unsafe.

It seems that either way it makes sense to do exactly what you described: encapsulate this workflow logic in a class independent of the computation steps. It should support cancellation and/or interruption and accept a bunch of tasks to be executed. Note that the tasks to be fed into the workflow should provide at least two methods: one to perform the computation and one to roll it back.

Upvotes: 1

Lukas Eder
Lukas Eder

Reputation: 220952

I am not aware of such a mechanism. Since you have to track your work in order to be able to perform rollbackWork(), a well-designed object-oriented solution is your best choice anyway, if you want to further evolve this logic! Typically, such a scenario could be implemented using the command pattern, which I still find pretty lightweight:

// Task or Command
public interface Command {
    void redo();
    void undo();
}

A scheduler or queue could then take care of executing such task / command implementations, and of rolling them back in order.

Upvotes: 4

Related Questions