Thank you, I have been looking into derby manuals in order to understand how Derby works and thinking of trying out some things, C-JDBC looks interesting for example.
Sth else, in my case I will probably have one workspace so the real question is whether I should keep a separate db for versioning or combine it with the one of the workspace. Regards Giota -----Original Message----- From: Stefan Guggisberg [mailto:[EMAIL PROTECTED] Sent: Monday, January 23, 2006 3:41 PM To: [email protected] Subject: Re: using one db for all filesystems and pms On 1/20/06, Giota Karadimitriou <[EMAIL PROTECTED]> wrote: > 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? i am not a derby expert but the derby project has excelllent documentation which you can find here: http://db.apache.org/derby/manuals/index.html > > 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? there's no duplication of data when using separate db's for each workspace. cheers stefan > > 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 > > > > >
