---

WORK IN PROGRESS

---

Proposal number : Persistence framework

Date	2008/06/19
Contact(s)	etj
Last edited	Timestamp
Status	draft
Assigned to release	to be determined
Resources	??? Indicate if the required resources are available to complete the proposal

Overview

Short description of the improvement proposal. ...

Proposal Type

• Type: GUI Change, Core Change, Module Change, Guideline and project governance procedures, ...
• App: GeoNetwork
• Module: eg. Harvester, Kernel, Data Manager, Metadata Import, Lucene Index, Search Interface ...

Links

• Documents: ​Hibernate spatial, ​Hibernate
• Email discussions: ​GN-devel thread
• Other wiki discussions:

Voting History

• Vote proposed by X on Y, result was +/-n (m non-voting members).

---

Motivations

The current configuration is .... A change to ....

As of version 2.2.0 the GeoNetwork application cannot be deployed to a cluster. Existing deployments probably haven't gotten to the size where clustering is necessary, but if this were to happen, deployment to a cluster will fail.

There are several reasons for this. Firstly, the application is storing non-Serializable objects in the HttpSession. Not terribly difficult to fix but is still a show stopper.

Secondly, and this is the real killer, the current mechanism of generating unique primary keys in jeeves.util.SerialFactory will fail in a cluster due to duplicate primary keys. The SerialFactory caches the max primary key values for each table. In a cluster multiple SerialFactory instances will exist and are oblivious of each other. The first node to insert a record will succeed, other nodes will fail.

Geoscience Australia has deployed GeoNetwork using Oracle. The correct way to deal with this in Oracle is to use a SEQUENCE. This requires generating Oracle specific SQL, something the project has avoided doing.

In my humble opinion, if GeoNetwork is to achieve its full potential it needs to be scalable. Issues like in memory key generation prevent this from occurring. The bottom line is you need to need to be DB independent but scalable. The project should seriously consider the adoption of a persistence framework such as Hibernate.

Proposal

An in depth proposal can be found here : link ...

Backwards Compatibility Issues

Risks

Participants

• List of participants and role (if necessary) in current GIP