Mercurial > hg > blitz_stable
comparison src/org/dancres/blitz/entry/package.html @ 0:3dc0c5604566
Initial checkin of blitz 2.0 fcs - no installer yet.
| author | Dan Creswell <dan.creswell@gmail.com> |
|---|---|
| date | Sat, 21 Mar 2009 11:00:06 +0000 |
| parents | |
| children |
comparison
equal
deleted
inserted
replaced
| -1:000000000000 | 0:3dc0c5604566 |
|---|---|
| 1 <body> | |
| 2 | |
| 3 <P> The blitz storage engine lives in this package and is responsible for | |
| 4 storage and indexing of MangledEntry instances. It is built around the concept | |
| 5 of virtual memory with EntrySleeves being the equivalent of pages which can | |
| 6 be cached or written to Storage instances. </P> | |
| 7 | |
| 8 <P> EntrySleeves contain a certain amount of transient information | |
| 9 (SleeveState) which is used to manage them whilst they are cached in | |
| 10 memory </P> | |
| 11 | |
| 12 <P> EntrySleeves may be pinned in memory using the PINNED flag. This | |
| 13 prevents any state changes made from being reflected to disk (this is most | |
| 14 often used to prevent writes getting to disk until the containing | |
| 15 transaction has commited). Other flags identify dirty, deleted or never | |
| 16 written EntrySleeves which determines what should be done when EntrySleeve | |
| 17 state is sync'd back to disk. </P> | |
| 18 | |
| 19 <P> Recently written entries are not immediately written to disk (though they | |
| 20 are logged) on the assumption that these Entries might well be immediately | |
| 21 taken which has the potential to save us a disk write/delete cycle. </P> | |
| 22 | |
| 23 <P> Note: flushing in this context means removal from the cache and can only | |
| 24 occur after sync'ing which is the copying of appropriate state to disk. Of | |
| 25 course, if the state of an EntrySleeve hasn't changed disk needn't be updated. | |
| 26 </P> | |
| 27 | |
| 28 <p> Storage management is mostly done in EntryStorage which delegates a lot | |
| 29 of responsibility to WriteScheduler (manages PINNED Sleeves). | |
| 30 WriteScheduler delegates handling of updates to WriteBuffer which | |
| 31 asynchronously updates disk via WriteDaemon. We use asynchronous writing | |
| 32 because it allows the upper layers to avoid waiting for disks to perform an | |
| 33 operation.</p> | |
| 34 | |
| 35 @see org.dancres.blitz.entry.SleeveState | |
| 36 @see org.dancres.blitz.entry.WriteScheduler | |
| 37 @see org.dancres.blitz.entry.WriteBuffer | |
| 38 @see org.dancres.blitz.disk.WriteDaemon | |
| 39 </body> |