Changes between Version 1 and Version 2 of persistence


Ignore:
Timestamp:
Jun 19, 2008, 5:18:36 PM (16 years ago)
Author:
etj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • persistence

    v1 v2  
    1313|| '''Status''' || draft ||
    1414|| '''Assigned to release''' || to be determined ||
    15 || '''Resources''' || ??? Indicate if the required resources are available to complete the proposal ||
     15|| '''Resources''' || ??? ||
    1616
    1717== Overview ==
    1818
    19 Short description of the improvement proposal.
    20 ...
     19Suggestions for using a persistence framework.
    2120
    2221=== Proposal Type ===
    2322 * '''Type''': GUI Change, Core Change, Module Change, Guideline and project governance procedures, ...
    2423 * '''App''': !GeoNetwork
    25  * '''Module''': eg. Harvester, Kernel, Data Manager, Metadata Import, Lucene Index, Search Interface ...
     24 * '''Module''': Data Manager, DB access
    2625
    2726=== Links ===
    … …  
    3130
    3231=== Voting History ===
    33  * Vote proposed by X on Y, result was +/-n (m non-voting members).
     32 * No vote requested yet.
    3433
    3534----
    3635
    3736== Motivations ==
    38 The current configuration is .... A change to ....
     37Snip from the aforementioned email discussion:
    3938
     39> As of version 2.2.0 the GeoNetwork application cannot be deployed to a
     40> cluster. Existing deployments probably haven't gotten to the size where
     41> clustering is necessary, but if this were to happen, deployment to a cluster
     42> will fail.
    4043
    41  As of version 2.2.0 the GeoNetwork application cannot be deployed to a
    42  cluster. Existing deployments probably haven't gotten to the size where
    43  clustering is necessary, but if this were to happen, deployment to a cluster
    44  will fail.
     44> There are several reasons for this. Firstly, the application is storing
     45> non-Serializable objects in the !HttpSession. Not terribly difficult to fix
     46> but is still a show stopper.
    4547 
    46  There are several reasons for this. Firstly, the application is storing
    47  non-Serializable objects in the HttpSession. Not terribly difficult to fix
    48  but is still a show stopper.
     48> Secondly, and this is the real killer, the current mechanism of generating
     49> unique primary keys in jeeves.util.!SerialFactory will fail in a cluster due
     50> to duplicate primary keys. The !SerialFactory caches the max primary key
     51> values for each table. In a cluster multiple !SerialFactory instances will
     52> exist and are oblivious of each other. The first node to insert a record will
     53> succeed, other nodes will fail.
    4954 
    50  Secondly, and this is the real killer, the current mechanism of generating
    51  unique primary keys in jeeves.util.SerialFactory will fail in a cluster due
    52  to duplicate primary keys. The SerialFactory caches the max primary key
    53  values for each table. In a cluster multiple SerialFactory instances will
    54  exist and are oblivious of each other. The first node to insert a record will
    55  succeed, other nodes will fail.
     55> Geoscience Australia has deployed GeoNetwork using Oracle. The correct way to
     56> deal with this in Oracle is to use a SEQUENCE. This requires generating
     57> Oracle specific SQL, something the project has avoided doing.
    5658 
    57  Geoscience Australia has deployed GeoNetwork using Oracle. The correct way to
    58  deal with this in Oracle is to use a SEQUENCE. This requires generating
    59  Oracle specific SQL, something the project has avoided doing.
    60  
    61  In my humble opinion, if GeoNetwork is to achieve its full potential it needs
    62  to be scalable. Issues like in memory key generation prevent this from
    63  occurring. The bottom line is you need to need to be DB independent but
    64  scalable. The project should seriously consider the adoption of a persistence
    65  framework such as Hibernate.
     59> In my humble opinion, if GeoNetwork is to achieve its full potential it needs
     60> to be scalable. Issues like in memory key generation prevent this from
     61> occurring. The bottom line is you need to need to be DB independent but
     62> scalable. The project should seriously consider the adoption of a persistence
     63> framework such as Hibernate.
     64
     65We'll also have to get independent from the spatial dbms used, so a persistence framework with spatial capabilities would be the better choice.
    6666
    6767== Proposal ==
    68 An in depth proposal can be found here : link
    69 ...
     68
     69The suggested framework is Hibernate Spatial.
     70...etc
     71
    7072
    7173=== Backwards Compatibility Issues ===
    7274
    7375== Risks ==
     76 * It has been reported (aaime) that H does use its cache a lot. When a search gives an high number of results, the cache could generate an !OutOfMemory error. This may be avoided using directQueries, which somehow don't use cache. It's a good solutions for read-only queries (and catalog queries are like that). This kind of queries may have drawbacks in terms of unusable lazy loads (an internal H feature), and this could lead to potential problems with an ebRIM based schema, because of the high number of related objects. This issue has been reported on an old H version (about start of 2007), so it may not be valid any longer.
    7477
    7578== Participants ==
    76  * List of participants and role (if necessary) in current GIP
     79 * ETj
     80 * Some ideas and discussions with A Aime, S Giannecchini, A Fabiani.
    7781