DISKUSE
RTF Scrollbar (2)
21.01.2021 23:27

Export textu do hlavičky MS Word dokumentu pomocí ... (2)
21.01.2021 18:48

Nemá created (2)
09.01.2021 08:46

Problém s polem From v mailech posílaných přes SMT... (1)
30.11.2020 14:30

Agent log (1)
04.08.2020 13:17

Traveler se nepřipojí (2)
25.06.2020 08:20

Výběr lidí z AK tiskne jen 3 (2)
22.05.2020 07:41

Sametime 8.0.2
20.05.2020 15:22

21.01.2021 23:27

Export textu do hlavičky MS Word dokumentu pomocí ... (2)
21.01.2021 18:48

Nemá created (2)
09.01.2021 08:46

Problém s polem From v mailech posílaných přes SMT... (1)
30.11.2020 14:30

Agent log (1)
04.08.2020 13:17

Traveler se nepřipojí (2)
25.06.2020 08:20

Výběr lidí z AK tiskne jen 3 (2)
22.05.2020 07:41

Sametime 8.0.2
20.05.2020 15:22

ŠKOLENÍ
REKLAMA
KOMENTÁŘE
Druhý díl miniseriálu s podtitulem Architektúra Unread Marks.
Architektúra Unread Marks
Ako nástroj tejto architektúry použili dva komponenty:
Unread Journal je tabuľka záznamov o čítacích aktivitách klienta Notes. Inak povedané – je to akýsi "log". UJ je uložený mimo databázy v súbore Cache.ndk (resp. Cache.dsk) dátového adresára Notes klienta. Samotný obsah UJ predstavujú riadky s UNID číslami dokumentov, ktoré boli prečítané resp. boli označené ako neprečítané.
Pre ujasnenie - najdôležitejšie UJ fakty:
Unread Table je tabuľka, v ktorej sú zapísané NoteID nečítaných dokumentov pre daného používateľa. Inak povedané: Koľko používateľov otvorilo databázu, toľko UT vzniklo. Jednotlivé UT sú uložené priamo v databáze vo forme špeciálnych dokumentov (Note), pričom ich identifikátorom je hierarchické meno používateľa. Pre zjednodušenie sa dajú porovnať s profile dokumentmi, ktorých kľúčom je @UserName. Na rozdiel od nich sa však počas replikácie neprenáša (rozdiel nastal vo verzii 6.03 – ale o tom až v ďalšej časti). Samotný obsah UT predstavujú riadky s číslami NoteID dokumentov, ktoré daným používateľom neboli prečítané (resp. neboli označené ako prečítané).
Takže ešte raz, najdôležitejšie UT fakty:
Prečo tak komplikovaný UM aparát? Odpoveď je jednoduchá: Distribuované prostredie Domino/Notes, kde je potrebné zabezpečiť používateľovi "jednotnú" informáciu o stave čítania/nečítania dokumentov, nezávisle od repliky. Keďže UT sa automaticky nereplikuje (až od istých verzií a aj to len pre workstation/server), bol ako synchronizačný "engine" použitý UJ. V nasledujúcej kapitole je na konkrétnom príklade objasnený mechanizmus synchronizácie.
Pri návrhu architektúry UM vychádzali jej tvorcovia z nasledujúcich axióm:
- Pre každého používateľa bude existovať v databáze jeho vlastný index nečítaných dokumentov
- Pre viac replík databázy sa tento index nebude prenášať
- Pri aktívnej práci s databázou a budú informácie zapisovať aj lokálne (mimo databázu) tak, aby v prípade otvorenia inej repliky bol zosynchronizovaný index
Ako nástroj tejto architektúry použili dva komponenty:
- Unread Journal (UJ)
- Unread Table (UT)
Unread Journal je tabuľka záznamov o čítacích aktivitách klienta Notes. Inak povedané – je to akýsi "log". UJ je uložený mimo databázy v súbore Cache.ndk (resp. Cache.dsk) dátového adresára Notes klienta. Samotný obsah UJ predstavujú riadky s UNID číslami dokumentov, ktoré boli prečítané resp. boli označené ako neprečítané.
Pre ujasnenie - najdôležitejšie UJ fakty:
- UJ nie je súčasťou databázy, ale klientského prostredia v súbore Cache.ndk
- UJ obsahuje zoznam aktivít o čítaní dokumentov
- Dokument je identifikovaný cez UNID, čo je jedinečné v rámci všetkých replík
- UJ je limitovaná veľkosťou
Unread Table je tabuľka, v ktorej sú zapísané NoteID nečítaných dokumentov pre daného používateľa. Inak povedané: Koľko používateľov otvorilo databázu, toľko UT vzniklo. Jednotlivé UT sú uložené priamo v databáze vo forme špeciálnych dokumentov (Note), pričom ich identifikátorom je hierarchické meno používateľa. Pre zjednodušenie sa dajú porovnať s profile dokumentmi, ktorých kľúčom je @UserName. Na rozdiel od nich sa však počas replikácie neprenáša (rozdiel nastal vo verzii 6.03 – ale o tom až v ďalšej časti). Samotný obsah UT predstavujú riadky s číslami NoteID dokumentov, ktoré daným používateľom neboli prečítané (resp. neboli označené ako prečítané).
Takže ešte raz, najdôležitejšie UT fakty:
- UT je súčasťou databázy, nie klientského prostredia
- UT je jedinečná pre používateľa (@UserName)
- UT sa nereplikuje medzi replikami databázy
- UT obsahuje zoznam nečítaných dokumentov
- Nečítaný dokument je identifikovaný cez NoteID, čo je však jednoznačné len v danej replike databázy
Prečo tak komplikovaný UM aparát? Odpoveď je jednoduchá: Distribuované prostredie Domino/Notes, kde je potrebné zabezpečiť používateľovi "jednotnú" informáciu o stave čítania/nečítania dokumentov, nezávisle od repliky. Keďže UT sa automaticky nereplikuje (až od istých verzií a aj to len pre workstation/server), bol ako synchronizačný "engine" použitý UJ. V nasledujúcej kapitole je na konkrétnom príklade objasnený mechanizmus synchronizácie.
Autor: Miroslav Uhlár
Datum: 24.05.2004
Sdílet článek Seznam komentářů
Zatím nebyl přidán žádný komentář. Buďte první!
Související články: