Changes between Version 1 and Version 2 of proposals/readonly


Ignore:
Timestamp:
Jan 23, 2013, 12:35:55 AM (11 years ago)
Author:
heikki
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • proposals/readonly

    v1 v2  
    3131== Proposal ==
    3232
    33 === services ===
     33=== read-write services ===
    3434
    3535A new abstract class !NotInReadOnlyModeService is introduced, which will be the base class of all services that do CUD (create, update, delete) operations on the DB. This class implements Jeeves' Service as do all services. It's {{{exec()}}} method checks whether GeoNetwork is running in read-only mode and if so, it does nothing. If not, it delegates to {{{serviceSpecificExec()}}}, where the affected services should put their normal (non-read-only) execution code.
     
    4141=== determining read-only status ===
    4242
    43 Currently this is determined by the presence of a configuration parameter in config.xml. As we speak, we're investigating how to improve on this so its status can be adapted dynamically in the event the database becomes read-only, so no restart of GeoNetwork is necessary.
     43The read-only status of GeoNetwork is determined by a periodic 'DB heartbeat' that attempts to write (and delete) a value in the database. If the situation changes (i.e. GN is not read-only but fails to write, or GN is read-only but succeeds writing) the read-only status of GN is dynamically adapted.
     44
     45=== other changes ===
     46
     47There are cases where the DB-writing part of a service is that small that it is better to restrict these writes at a level below the service, to still allow the service to run also in read-only mode. An example is metadata view: this service write to the DB updating the metadata's popularity. Even so it is not made a !NotInReadOnlyModeService, so also in read-only mode you can still use this service; instead the db-writing part is made conditional on readonly state at a level below the service. (of course this may be seen as a design flow in the service behaviour and you could argue that there should exist a separate service to update the popularity -- but refactoring is outside the scope of this proposal).
    4448
    4549=== GUI ===