This information was very useful; however I would like to pose some additional questions and forgive me if I ask sth which is pretty obvious.
I would like to use derby and db persistence manager in a clusterable environment in a J2EE web-app. Does this mean that I would have to go for the standalone derby server solution (in which case I would have to use SimpleDbPersistenceManager instead of DerbyPersistenceManager). I assume yes but would there be a way to use an embedded Derby instance? In this case and in a clustered environment when should I close the derby embedded connection? Furthermore, what is the common practice to be followed: many databases or one? What would be the reason to use only one derby db besides economy? I would like to follow the pattern I saw in most emails in the list (one db for each workspace home and one for versioning) but would this lead to enormous duplication of data/problems etc? Could somebody point me to some thread/ article besides this one in order to start understanding more in depth the whole derby persistence process? Regards Giota -----Original Message----- From: Stefan Guggisberg [mailto:[EMAIL PROTECTED] Sent: Thursday, January 19, 2006 12:32 PM To: [email protected] Subject: Re: using one db for all filesystems and pms 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/cor e/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 >
