Difference between revisions of "Digital Library Administration"
(→Content Management) |
|||
| Line 5: | Line 5: | ||
== VO and Users Management == | == VO and Users Management == | ||
| − | == Content Management == | + | == Content & Storage Management == |
| + | |||
| + | Content Management strictly relies on Storage Management. Therefore it is a prerequisite to setup a running instance of Storage Management before Content Management can be successfully started. There are two possibilities to setup Storage Management: a simple one using Apache Derby as a database backend and an advanced one, where an existing database is used via JDBC. | ||
| + | |||
| + | === Simple Setup of Storage Management using Apache Derby === | ||
| + | |||
| + | Apache Derby ([http://db.apache.org/derby/]) is an open source relational database implemented entirely in Java and available under the Apache License, Version 2.0 with a small footprint of about 2 megabytes. It is sufficient to be used as a database backend for getting started with Storage Management. However, when much data is stored or some more elaborate backup & recovery strategies should get used, traditional (huge) RDBMS might be a better choice. | ||
| + | |||
| + | If Storage Management is deployed dynamically or manually from the GAR, it's default installation places a configuration file in $GLOBUS_LOCATION/etc/<Service-Gar-Filename>/StorageManager.properties that expects Derby to be available and have permissions to write at file under ./StorageManagementService/db/storage_db. | ||
| + | Derby is started in embedded mode, for which it doesn't even need a username or password. Multiple connections from the same Java Virtual Machine are possible and are also quite fast, but no two Java VM can access the DB at the same time. | ||
| + | |||
| + | If all dependencies have been installed correctly, the container should start and create a new database if needed. | ||
| + | |||
| + | The lines defining the JDBC connection to the database in the above mentioned configuration files are: | ||
| + | |||
| + | <pre> | ||
| + | DefaultRawFileContentManager=jdbc\:derby | ||
| + | DefaultRelationshipAndPropertyManager=jdbc\:derby | ||
| + | # derby settings (Default) | ||
| + | jdbc\:derby.class=org.diligentproject.contentmanagement.baselayer.rdbmsImpl.GenericJDBCDatabase | ||
| + | jdbc\:derby.params.count=4 | ||
| + | jdbc\:derby.params.0=local_derby_storage_db | ||
| + | jdbc\:derby.params.1=org.apache.derby.jdbc.EmbeddedDriver | ||
| + | jdbc\:derby.params.2=jdbc\:derby\:./StorageManagementService/db/storage_db;create\=true | ||
| + | jdbc\:derby.params.3=5 | ||
| + | </pre> | ||
| + | |||
| + | By changing the <pre>jdbc\:derby.params.2=jdbc\:derby\:./StorageManagementService/db/storage_db;create\=true</pre> after derby\: you can choose another place to store the database. | ||
| + | In this setting, all relationships and properties as well as the raw file content are stored inside the Derby database. This is defined in the first two lines of the configurtaion snipped shown above. | ||
| + | |||
| + | === Advanced Setup of Storage Management using an arbitrary relationanl JDBC-Database === | ||
== Metadata Management == | == Metadata Management == | ||
Revision as of 16:41, 23 July 2007
Contents
VDL Creation and Management
Resources Management
VO and Users Management
Content & Storage Management
Content Management strictly relies on Storage Management. Therefore it is a prerequisite to setup a running instance of Storage Management before Content Management can be successfully started. There are two possibilities to setup Storage Management: a simple one using Apache Derby as a database backend and an advanced one, where an existing database is used via JDBC.
Simple Setup of Storage Management using Apache Derby
Apache Derby ([1]) is an open source relational database implemented entirely in Java and available under the Apache License, Version 2.0 with a small footprint of about 2 megabytes. It is sufficient to be used as a database backend for getting started with Storage Management. However, when much data is stored or some more elaborate backup & recovery strategies should get used, traditional (huge) RDBMS might be a better choice.
If Storage Management is deployed dynamically or manually from the GAR, it's default installation places a configuration file in $GLOBUS_LOCATION/etc/<Service-Gar-Filename>/StorageManager.properties that expects Derby to be available and have permissions to write at file under ./StorageManagementService/db/storage_db. Derby is started in embedded mode, for which it doesn't even need a username or password. Multiple connections from the same Java Virtual Machine are possible and are also quite fast, but no two Java VM can access the DB at the same time.
If all dependencies have been installed correctly, the container should start and create a new database if needed.
The lines defining the JDBC connection to the database in the above mentioned configuration files are:
DefaultRawFileContentManager=jdbc\:derby DefaultRelationshipAndPropertyManager=jdbc\:derby # derby settings (Default) jdbc\:derby.class=org.diligentproject.contentmanagement.baselayer.rdbmsImpl.GenericJDBCDatabase jdbc\:derby.params.count=4 jdbc\:derby.params.0=local_derby_storage_db jdbc\:derby.params.1=org.apache.derby.jdbc.EmbeddedDriver jdbc\:derby.params.2=jdbc\:derby\:./StorageManagementService/db/storage_db;create\=true jdbc\:derby.params.3=5By changing the
jdbc\:derby.params.2=jdbc\:derby\:./StorageManagementService/db/storage_db;create\=trueafter derby\: you can choose another place to store the database.
In this setting, all relationships and properties as well as the raw file content are stored inside the Derby database. This is defined in the first two lines of the configurtaion snipped shown above.
