On 1/19/06, Brian Moseley <[EMAIL PROTECTED]> wrote: > has anybody configured jackrabbit to use a single database for all > repository and workspace filesystems and persistence managers? > > i'm trying out a configuration that uses a single derby db for all of > jackrabbit. this seems easier to manage than five separate databases. > this setup seems to function ok until the repository is shutdown. at > this point it looks like the first filesystem or persistence manager > to be closed closes the derby connection, causing the next component's > close to fail.
DerbyPersistenceManager assumes the derby database to be embedded; see http://incubator.apache.org/jackrabbit/apidocs/org/apache/jackrabbit/core/state/db/DerbyPersistenceManager.html in fact it only overrides the close() method of SimpleDbPersistenceManager in order to properly shutdown the embedded derby instance. what you probably want to use is a standalone derby server in which case you can use SimpleDbPersistenceManager instead of DerbyPersistenceManager. e.g. <PersistenceManager class="org.apache.jackrabbit.core.state.db.SimpleDbPersistenceManager"> <param name="driver" value="org.apache.derby.jdbc.ClientDriver"/> <param name="url" value="jdbc:derby://localhost/jackrabbit;create=true"/> <param name="schema" value="derby"/> <param name="schemaObjectPrefix" value="${wsp.name}_"/> <param name="externalBLOBs" value="false"/> </PersistenceManager> alternatively you could still use an embedded derby database but using SimpleDbPersistenceManager instead of DerbyPersistenceManager. note that in this case you would have to exlicitly shutdown the embedded derby database yourself. the derby manuals can be found here: http://db.apache.org/derby/manuals/index.html > > are there any concerns about using a single unified database? no > what might be a good strategy for modifying jackrabbit to support this > configuration? perhaps SimpleDbPersistenceManager and DbFilesystem > should simply ignore closed connections when shutting themselves down? i don't think that that would be a good idea. see alternatives above. cheers stefan >
