jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Giota Karadimitriou" <Giota.Karadimitr...@eurodyn.com>
Subject RE: using one db for all filesystems and pms
Date Fri, 20 Jan 2006 17:43:18 GMT
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:stefan.guggisberg@gmail.com] 
Sent: Thursday, January 19, 2006 12:32 PM
To: jackrabbit-dev@incubator.apache.org
Subject: Re: using one db for all filesystems and pms

On 1/19/06, Brian Moseley <bcm@osafoundation.org> 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

>


Mime
View raw message