Черновик. Коротко. Для себя.
Про переделку 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 лет +". Наверное "вероятность попадания в ошибочную ветку - очень маленькая". Эх. Посчитать бы вероятность.
Про переделку 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 лет +". Наверное "вероятность попадания в ошибочную ветку - очень маленькая". Эх. Посчитать бы вероятность.
Комментариев нет:
Отправить комментарий