jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessandro Bologna <alessandro.bolo...@gmail.com>
Subject Re: restore workspace with OraclePersistenceManager on different machine?
Date Fri, 27 Jul 2007 14:00:27 GMT
Wouldn't it be more appropriate to configure the second repository as  
a clustered (http://wiki.apache.org/jackrabbit/Clustering) instance?
I think that Phillip wants to have the second repository's indexed  
updated when there's any data change.

On Jul 27, 2007, at 9:52 AM, Stefan Guggisberg wrote:

> hi philip,
> On 7/26/07, Phillip Rhodes <spamsucks@rhoderunner.com> wrote:
>> Hello,
>> I have a instance of jackrabbit running with  
>> OraclePersistenceManager on a remote machine.
>> I would like to setup a second (readonly) repository on my local  
>> machine that shares the same data as the aforementioned repository  
>> so that I can do some analysis on some performance problems that I  
>> am having.
>> I thought by just starting up the repository on my local machine  
>> with the OraclePersistenceManager configured the same as the first  
>> repository (same database instance) would cause jackrabbit to  
>> recreate the workspace directories and index directories and set  
>> them up for use, but alas, this is not the case.
>> Any xpath query that I perform fails to return anything.
>> I would appreciate any help and guidance on getting past this so I  
>> can dig deeper in what part of my usage of jackrabbit is causing  
>> problems.  Is there a way to instruct jackrabbit to refresh the  
>> filesystem using the PersistenceManager as it's source for data?
> please note that the repository home directory contains vital data
> (such as custom node types and namespaces). you need to copy the
> contents of your repository home directory
> (except the index folders) to the other machine.
> alternatively you could configure jackrabbit to store everything
> (except the index) in the db
> by using DbFileSystem instead of LocalFileSystem. however, i  
> wouldn't recommend
> it in general as you cannot easily read/edit the information stored in
> the DbFileSystem.
> btw: here's a related issue: http://issues.apache.org/jira/browse/ 
> JCR-964
> cheers
> stefan
>> Thanks.
>> Phillip

View raw message