Il sistema di locking sui documenti è decisamente cambiato rispetto al comportamento di HighWay.
Lo scopo è garantire che chi prenota un documento per i propri scopi (tipicamente la modifica) abbia facoltà di mantenerne la proprietà per tutta la durata utile dell'operazione indipendentemente da fattori esterni che potrebbero causare la disconnessione dal server, imputabili alla componente Java dell'applicazione o al server stesso. In tal modo non si vanifica l'operato di colui che modifica un documento complesso e, volendolo salvare, non trova più la connessione con il server che aveva.
Ciò è dovuto anche al fatto che non si ha alcuna garanzia che la modifica venga effettuata dallo stesso server che ha compiuto la prenotazione del documento quindi si è reso necessario studiare un sistema che non fosse legato alle funzionalità di locking del sistema operativo (se non in modo secondario).
Nel file che avete identificato, quindi, viene registrato l'operatore che ha richiesto il documento, il timestamp di quando questa richiesta ha avuto luogo ed un codice di controllo che identifica la proprietà del documento stesso. Un operatore può quindi richiedere la proprietà di un documento, portarselo a casa, modificarlo ed il giorno successivo procedere all'aggiornamento a patto che conosca quel codice e che esso non sia scaduto. Infatti la prenotazione ha un tempo utile, scaduto il quale il documento è nuovamente prenotabile (mentre la sua consultabilità) è garantita.
L'iter di prenotazione è il seguente:
<profile type="check_time" value="180"/>
... è quello che ci vuole. Il sistema non è disattivabile in quanto sarebbe assolutamente insicuro compiere salvataggi di documenti senza averne prima acquisito la proprietà. E' altresì possibile impostare valori di check_time molto brevi ma questo può influenzare sensibilmente il comportamento delle operazioni (come dicevo prima non sono certo di quale sia il comportamento del server di fronte ad una modifica o cancellazione di un documento non prenotato o con prenotazione scaduta).
Per quanto concerne la verifica del server basata sugli IP essa viene attivata autonomamente dal server all'atto della partenza indipendentemente dal fatto che il file di xreg.conf.xml sia presente e registri le attività nei log di registro (appunto) in quanto, diversamente da HighWay/HiCount, le due operazioni sono slegate.
Fa fede l'utente che viene notificato al server dal Broker, utente che il server registra nel file xusers.xml (directory conf).
Viene quindi verificata la provenienza dello stesso utente da IP address diversi entro gli ultimi 5 minuti e se ciò avviene, l'operazione viene rifiutata. Per ovviare a questo problema si può:
a) Introdurre nel file xreg.conf.xml una configurazione del tipo <xreg_cfg> <global allow_collision="true"> </xreg_cfg>
b) Modificare il file xusers.xml per l'utente che si vuol lasciar passare indipendentemente dall'IP address di provenienza introducendo nell'elemento che lo identifica l'attributo cgiuser con valore true.
Torna a Indice delle voci