Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #6987

Re: A quota based lock

Show all headers | View raw

On Wed, 10 Aug 2011 18:55:43 +0200, Robert Klemme wrote:

> This can never work: if you have jobs that - by design - hold the
> resource for hours then no amount of lock implementation smartness will
> prevent starvation without preemption.  You cannot have a resource with
> exclusive access, long access times and responsiveness at the same time.
>   Doing preemption manually will be difficult.  It's better to break up
> long running tasks into smaller sub tasks which need exclusive resource
> access.  Whether that's possible or not depends of course on your
> business logic (which we still haven't seen).
>
Total agreement. 

If you have a long running job that requires exclusive resource access, 
then by definition no other task will ever get a look-in while its 
running. 

If such long running background jobs are doing housekeeping tasks on a 
database, which they often are, its usually possible to identify 
relatively short processing cycles that amend the database and can be 
split out into separate transactions that run in the same timescale as 
online transactions. By splitting the task up this way it can take its 
turn in obtaining the resource lock for each transaction and your locking 
mechanism may not need to be any more complex that a FIFO queue. 

The long-running task may run a bit shower due to transaction commit 
overheads and (possibly) a need to save running totals between 
transactions, but often the running totals etc can be collected in a 
separate read-only, and hence non-locking, transaction and the results 
committed in separate, short update transaction. 

On the bright side, if the long process is redesigned along these lines 
and also keeps track of progress, it will recover *much* faster when a 
system crash, exception or whatever occurs while its running.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

A quota based lock Robert Stark <panxiaozhong@gmail.com> - 2011-08-08 00:13 -0700
  Re: A quota based lock Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-08-08 07:58 -0400
    Re: A quota based lock Knute Johnson <september@knutejohnson.com> - 2011-08-08 09:48 -0700
      Re: A quota based lock markspace <-@.> - 2011-08-08 10:00 -0700
        Re: A quota based lock Knute Johnson <september@knutejohnson.com> - 2011-08-08 11:39 -0700
          Re: A quota based lock markspace <-@.> - 2011-08-08 11:57 -0700
            Re: A quota based lock Robert Klemme <shortcutter@googlemail.com> - 2011-08-08 21:46 +0200
              Re: A quota based lock Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-08-08 20:41 -0400
                Re: A quota based lock Robert Klemme <shortcutter@googlemail.com> - 2011-08-10 09:36 +0200
                Re: A quota based lock Robert Stark <panxiaozhong@gmail.com> - 2011-08-10 04:40 -0700
                Re: A quota based lock Robert Klemme <shortcutter@googlemail.com> - 2011-08-10 18:55 +0200
                Re: A quota based lock Martin Gregorie <martin@address-in-sig.invalid> - 2011-08-10 19:26 +0000
                Re: A quota based lock Patricia Shanahan <pats@acm.org> - 2011-08-10 12:37 -0700
                Re: A quota based lock Robert Stark <panxiaozhong@gmail.com> - 2011-08-10 18:30 -0700
                Re: A quota based lock markspace <-@.> - 2011-08-10 19:17 -0700
                Re: A quota based lock Robert Klemme <shortcutter@googlemail.com> - 2011-08-11 12:32 +0200
          Re: A quota based lock Tom Anderson <twic@urchin.earth.li> - 2011-08-09 21:00 +0100
  Re: A quota based lock markspace <-@.> - 2011-08-08 07:58 -0700
  Re: A quota based lock Tom Anderson <twic@urchin.earth.li> - 2011-08-09 21:45 +0100

csiph-web