понедельник, 8 сентября 2014 г.

Черновик. Коротко. Для себя

Черновик. Коротко. Для себя.

Про переделку IStorage

1. (done) Перенести Lock/Unlock в HeaderData.

2. Лочить HeaderData в конструкторе/деструкторе ТОЛЬКО если открываем НА ЗАПИСЬ.

3. Во всех остальных Read/Write лочить только непосредственно при "доступе к диску". Вложенно. Со счётчиком f_Lock.

4. Избавиться от aNeedLock. Заменить его на фабрику HeaderData, где параметром является aPosition. С владением HeaderData->HeaderDataFactory и Subscibe/Unsubscribe. Чтобы не держать РОДИТЕЛЬСКИЙ IStorage ЛИШНЕЕ ВРЕМЯ.

5. Проверить стратегию MainStorage и GetVersionsStorage. Если УЖЕ что-то открыто на ЗАПИСЬ,а мы хотим на ЧТЕНИЕ, то и это нам подходит.

6. Проверить Tm3StorageIndexStream на предмет Access. Если Storage требует только Read (а не Create/Delete), то открывать Tm3StorageIndexStream на ЧТЕНИЕ и не более того.

7. Проверять в Tm3Storage.Create данные Access vs. FRootStream.Access. Чтобы не открыли на ReadWrite поверх FRootStream. который открыт на ТОЛЬКО Read.

8. (done) Писать Lock/Unlock в log-файлы рядом с хранилищем - *.stg.log, *.sav.log, *_bkp.sav.log. С именем станции (ComputerName) и именем приложения (ParamStr(0)). Чтобы можно было "читать глазами", когда вдруг получаем Lock Violation.

9. Писать данные HeaderData НЕПОСРЕДСТВЕННО в методах pm_SetXXX. Чтобы не было рассинхронизации данных.

10. (done) Унаследовать RootStreamManager и HeaderData от "примеси" с Losk/Unlock. И защищать FRootStream и Data.

11. НУ и конечно же -ДОУБРАТЬ ВСЕ with из m3StgCla.

Я вот перечитываю то, что написал выше и ОДИН только вопрос меня тревожит - "как это всё работало 15 лет +". Наверное "вероятность попадания в ошибочную ветку - очень маленькая". Эх. Посчитать бы вероятность.

Комментариев нет:

Отправить комментарий