com.sun.jini.reggie
Class RegistrarImpl.SnapshotThread
java.lang.Object
java.lang.Thread
com.sun.jini.thread.InterruptedStatusThread
com.sun.jini.reggie.RegistrarImpl.SnapshotThread
- All Implemented Interfaces:
- Runnable
- Enclosing class:
- RegistrarImpl
private class RegistrarImpl.SnapshotThread
- extends InterruptedStatusThread
Snapshot-taking thread.
A snapshot is taken when -- after writing a new record to the
log file -- it is determined that the size of the log file has
exceeded a certain threshold. The code which adds the new record
to the log file and which, in turn, decides that a snapshot
must be taken is "wrapped" in a writer mutex. That is, synchronization
of processing is achieved in the Registrar through a "reader/writer"
mutex construct. This construct allows only one writer at any one
time; but allows an unlimited number of simultaneous readers as
long as no writer has locked the mutex. During steady-state, it is
anticipated that there will be far more readers (e.g. lookups) in use
than writers (e.g. add/mod/del Attributes). Since the process of
taking a snapshot can be time-consuming, if the whole snapshot-taking
process occupies that single writer mutex, then a significant number
of read requests will be un-necessarily blocked; possibly resulting
in an unacceptable degradation in response time.
It is for the above reason that the process of taking a snapshot is
performed in a separate thread. The thread waits on the monitor
belonging to the snapshotNotifier instance until it is notified
(or "signalled") that a snapshot must be taken. The notification
is sent by another thread, created by the Registrar, which
determines when the conditions are right for a snapshot. The
notification takes the form of an interrupt indicating that the
Snapshot monitor is available. Although the interrupt is sent
while the writer mutex is locked, the act of sending the notification
is less time-consuming than the act of taking the snapshot itself.
When the thread receives a notification, it awakens and requests a
lock on the reader mutex (this is all done in the readerWait() method).
Because a reader -- not a writer -- mutex is locked, read-only
processes still have access to the system state, so lookups can be
performed; and the reader mutex prevents changes to the data while
the snapshot is in progress.
Note that the current snapshot is guaranteed to complete before the
next snapshot request is received. This is because even though
the act of taking a snapshot can be viewed as a writer process,
the fact that the next snapshot notification will be wrapped in a
writer mutex, combined with the fact that a writer mutex can not
be locked while a reader mutex is locked, allows the snapshot to
be treated as a reader process.
Method Summary |
void |
run()
|
Methods inherited from class java.lang.Thread |
activeCount, checkAccess, clone, countStackFrames, currentThread, destroy, dumpStack, enumerate, getAllStackTraces, getContextClassLoader, getDefaultUncaughtExceptionHandler, getId, getName, getPriority, getStackTrace, getState, getThreadGroup, getUncaughtExceptionHandler, holdsLock, interrupted, isAlive, isDaemon, isInterrupted, join, join, join, resume, setContextClassLoader, setDaemon, setDefaultUncaughtExceptionHandler, setName, setPriority, setUncaughtExceptionHandler, sleep, sleep, start, stop, stop, suspend, toString, yield |
RegistrarImpl.SnapshotThread
public RegistrarImpl.SnapshotThread()
- Create a daemon thread
run
public void run()
- Specified by:
run
in interface Runnable
- Overrides:
run
in class Thread
Copyright 2007-2010, multiple authors.
Licensed under the Apache License, Version 2.0, see the NOTICE file for attributions.