The write once store has a number of performance advantages. But first...

When Not To Use

If your application mainly updates a constant set of objects, and you are not interested in historical data, then the write once store is not appropriate.

For certain styles of use, it will simply grow uncontrollably in size.

Be aware.

When To Use

If you are mainly adding new data - such as store oriented transactions - then the write-once store is perfect.

Also, if there are minimal updates of any kind, then the low-overhead write-once store will be suitable.

Allocation Algorithm

None needed.

Resource Overhead For Large Store

None.

Well, clearly something somewhere has to be managing access to the data, but in the storage component there is no additional overhead.

File Size Adjustment

Since there are no allocators, it is simply a case of extending the file size in reasonable chunks. The algorithm used is pretty rough and ready but works well enough. The file size is doubled until it reaches 1Mb. Then it is increased by 1Mb at a a time until it reaches 10Mb, after which it is increased 4Mb at a time. These numbers seemed reasonable at the time and there has been no need to change them.

Transaction Considerations

Since there are no allocators, the commit overhead in the write-once store is less than in the read-write store.

Even so, when updating sets of objects, transactions should be used since each commit will write a new copy of the store header.

Store Compaction

This is not relevant at this level, since the store would need to be able to analyse address references within the data stored. Compaction is supported at the level of the GPO Model.