Mercurial > hg > blitz_condensed
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> |