You can have several DSpace instances running at one database. You just need different tablespaces. And then You must do some changes in dspace.cfg. May be it is possible to copy the PROD table space to a STAGING tablespace - but I am not sure how DSpace will react. Maybe there are some internal settings depending on the tablespace and the tomcat port and so on.
We are running 1.5 JSPUI in a similar situation - but we did not reach the PROD stage. We have a DEV and a QA installation and thought about mirroring the QA to a PROD environment (it is a Xen virtual machine). But the last step is not tested until now - and of course we will have to make some configuration changes. I like Your idea about a STAGING step. Greetings Robert --------- Randy Stern schrieb: > Wondering if anyone has a solution to this configuration problem: > > We are making various modifications to the DSpace 1.5 XMLUI, which requires > us to periodically test and release updated versions of software. We are > having trouble figuring out how to configure a pre-production staging > instance of DSpace. Normally, we would like to push all changes through a > series of instances: > DEV - private DEV tomcat instance, database and assetstore > QA - private QA tomcat instance, database and assetstore > STAGING - private STAGING tomcat instance, but using the > PUBLIC database and assetstore > PROD - public PROD tomcat instance, database and assetstore > > The goal of STAGING is to test all code in a "production configuration", > e.g. with all production settings in dspace.cfg, before moving the changed > code to production with essentially a file copy. > > We tried setting STAGING up with a local copy of the PROD assetstore, and > with the database as read only, and this failed to run. Apparently DSpace > needs to write to the database at startup. Is this true? > > If DSpace must write to the database, then we may want to leave the > database as read/write. A followup question would be: is it safe to have > two instances of the DSpace tomcat webapp accessing the same database - > lets say so long as we do not submit any new items or modify items while > doing staging tests? Or will having two instances access the same database > cause the database to become corrupt? > > Appreciate any thoughts someone more knowledgeable than I would have on the > viability of setting up this type of environment. > > -Randy > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
