La presente documentazione intende discutere di una particolare esigenza che può interessare qualsiasi applicazione, in particolare quelle che contano un elevato numero di utenti consultatori ai quali si decida di assegnare il diritto di costituire proprie raccolte ed operare su di esse.
L'esigenza alla quale si fa riferimento consta nell'evitare una proliferazione incontrollata delle raccolte limitando le possibilità degli utenti più inesperti o regolarizzando l'uso delle stesse da parte degli utenti pià esperti e scaltri. Questo può fungere da limitazione agli abusi del sistema ma anche a compiere una semplice pulizia, ad esempio rimuovendo quelle raccolte per le quali si ha evidenza che non sono state più modificate da un certo tempo.
Vediamo come si implementa e come si controlla l'operato del thread preposto a questi scopi.
Al pari di altre procedure automatizzate presso il server Master, anche questa viene eseguita espressamente da un'estensione del server, un thread che ha questo compito. Il thread viene eseguito se e solo se esiste nella directory collect, che ospita le raccolte, un file denominato collect.conf.xml.
Questo file contiene un particolare formato, derivato dallo standard adottato qualche tempo fa dal server, che consente di indicare come operare per raccolte pubbliche e private.
Esso contiene quindi una sezione public ed una private per dichiarare come operare nei confronti delle une e delle altre. Nell'ambito delle raccolte private, inolte, è possibile che sia presente una sezione nome_utente entro la quale esplicitare eventualmente, in generale o file per file, quale regola applicare alle raccolte di quest'utente.
Avremo quindi una modalità generale per le raccolte pubbliche e per le raccolte private nonché una modalità generale anche per ogni singolo utente.
Tanto per le modalità generali, identificate dal valore .globalmode per non rischiare confusione con un nome di raccolta, quanto per le modalità specifiche degli utenti, si può esprimere la regola che indica se la raccolta sia cancellabile o meno e, se sì, a quali condizioni.
Di seguito l'elenco delle regole attualmente accettate:
permanent: Le raccolte identificate non devono mai essere rimosse per nessun valido motivo.creation_date: Questa regola è seguita dal carattere ':' e da un numero 'n'. Indica che le raccolte identificate devono essere rimosse dopo 'n' giorni dalla data di creazione della raccolta stessa. Questo tipo di regola si utilizza quando si vuole evitare che un utente possa alimentare proprie raccolte ad oltranza e modificarle di quando in quando per mantenerle sempre vive.modification_date: Questa regola è seguita dal carattere ':' e da un numero 'n'. Indica che le raccolte identificate devono essere rimosse dopo 'n' giorni dalla data di ultima modifica della raccolta stessa. Questo tipo di regola si utilizza quando ci si vuole semplicemente preoccupare di pulire l'albero delle raccole esistenti da quelle che sono cadute in disuso, che apparentemente non interessano più l'utente.units: Questa regola è seguita dal carattere ':' e da un numero 'n'. Indica che le raccolte identificate devono essere rimosse quando il loro contenuto raggiunge o supera le 'n' unità informative. Questo tipo di regola si utilizza quando ci si vuole tutelare dal fatto che un operatore possa selezionare una mole consistente dell'archivio, per meglio intenderci diciamo un estratto, per farne un uso eventualmente improprio (come ad esempio un'esportazione per creare un archivio proprio con dati omogenei).Le regole , in particolre per le raccolte publbiche, si applicano in cascata quindi in presenza di una regola specifica per una data raccolta, quella viene applicata, altrimenti si fa riferimento alla regola generale, ad esempio, dell'utente e, se assente, alla regola generale delle raccolte pubbliche. In sostanza, dalla regola più dettagliata a quella più generica, si applicherà la prima incontrata, quindi la più nidificata.
allfiles con valore booleano positivo o negativo (il default è negativo). Se si associa un valore positivo a questa voce, non solo le raccolte ma qualsiasi altro file presente in queste directory verrà rimosso se vetusto.Dal momento che un buon esempio vale più di 1000 parole, vediamo di seguito un campione del file collect.conf.xml.
<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE xwconf SYSTEM "http://www.3di.it/extraway/xwconf_20040930.dtd"> <xwconf> <section name="public"> <profile type=".globalmode" value="permanent"/> </section> <section name="private"> <profile type=".globalmode" value="permanent"/> <profile type=".allfiles" value="true"/> <section name="fginestrini"> <profile type=".globalmode" value="units:1000"/> <profile type="raccolta_associata_alla_ricerca_nome_nuova_ricerca_frequente_3" value="permanent"/> <profile type="raccolta_associata_alla_ricerca_costit_tetto" value="modification_date:45"/> </section> <section name="writelli"> <profile type=".globalmode" value="creation_date:100"/> </section> </section> </xwconf>
Nell'esempio di cui sopra vediamo che la regola globale per le raccolte pubbliche è che esse siano permanenti e, solo per le private, che la verifica sulla possibile rimozione dei files si estende anche ai files che non sono raccolte. Questo vale anche per tutte le raccolte private ad eccezione di quelle degli utenti fginestrini e writelli per i quali sono state indicare regole diverse.
L'utente fginestrini non avrà, in generale, raccolte contenenti più di 1000 unità informative. Nella fattispecie, una sua particolare raccolta denominata "raccolta associata alla ricerca nome nuove ricerca frequente 3" (opportunamente indicato secondo la modalità in cui si presentano i nomi dei files di raccolta su disco) sarà permanente mentre una diversa raccolta, denominata "raccolta
associata alla ricerca costit tetto", se presente, verrà rimossa dopo 45 giorni dalla sua ultima modifica.
Per l'utente writelli le raccolte avranno tutte un limite di tempo, non più di 100 giorni dalla loro data di creazione.
La configurazione che si ritiene possa essere la pià frequente, comunque, potebbe essere la successiva...
<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE xwconf SYSTEM "http://www.3di.it/extraway/xwconf_20040930.dtd"> <xwconf> <section name="public"> <profile type=".globalmode" value="permanent"/> </section> <section name="private"> <profile type=".globalmode" value="modification_date:180"/> </section> </xwconf>
...che si limita a fare pulizia rimuovendo tutte quelle raccolte private che non vengono più modificate da almeno sei mesi (180 giorni).
Dal momento che l'unità di misura, in termini di tempo, è il giorno, il thread preposto alla rimozione delle raccolte viene eseguito ogni 24 ore. Ciò significa che, trascorse 24 ore dalla fine dell'ultima esecuzione, il thread viene risvegliato e controlla nuovamente da capo ogni raccolta esistente.
Se al suo risveglio il thread rileva che il file di configurazoine collect.conf.xml risulta assente, la procedura viene interrotta. Se poi il file viene creato nuovamente, la procedura può essere riavviata.
Le operazioni compiute dal thread il cui compito è stato descritto nel paragrafo precedente vengono tutte registrate nei principali files di log: xw.log e xwannomese. In essi si presentano registrazioni aventi il seguente aspetto:log.
Innanzitutto viene indicato il momento in cui inizia il lavoro del thread con una registrazione come la seguente...
20050928155023.431 03836 [I]RmCollect: Starting Remove Job
La cancellazione dei files può quindi andar a buon fine e lasciare una registrazione come la seguente...
20050928155828.796 03836 [I]RmCollect: File c:\xw\collect\writelli\codicestrada.12 successfully removed
...oppure fallire lasciando una registrazione come la seguente...
20050928160001.437 03836 [E]RmCollect: Error removing file c:\xw\collect\fabio\raccolta_costit_tetto.30
Al termine del ciclo di verifica e cancellazione, che ovviamente potrebbe non rimuovere alcuna raccolta, la segnalazione sarà...
20050928160002.687 03836 [I]RmCollect: Ending Remove Job
Se poi vengono meno le condizioni per compiere i test (perché si presenta un errore oppure perché il file di configurazione viene cancellato) si avrà una registrazione come la seguente...
20050928160028.812 03836 [I]RmCollect: Exiting from main loop (0)
...indicando un valore diverso da 0 ed il tipo di log '[E]' qualora il ciclo si sia interrotto a causa di un errore.
Torna a Indice delle voci