You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Brian Moseley <bc...@osafoundation.org> on 2006/01/19 00:42:20 UTC
using one db for all filesystems and pms
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.
are there any concerns about using a single unified database? 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?
Re: using one db for all filesystems and pms
Posted by Brian Moseley <bc...@osafoundation.org>.
On 1/19/06, Stefan Guggisberg <st...@gmail.com> wrote:
> one reason are the prepared statements that are associated with a connection.
> another reason are transactions, i.e. connection needs to be the same during
> the scope of a jcr transaction.
> last but not least i wanted to keep the implementation simple.
makes sense. thanks!
Re: using one db for all filesystems and pms
Posted by Stefan Guggisberg <st...@gmail.com>.
On 1/19/06, Brian Moseley <bc...@osafoundation.org> wrote:
> On 1/19/06, Stefan Guggisberg <st...@gmail.com> wrote:
>
> > 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.
>
> this is what i was slowly convincing myself to try, so i'm glad to
> hear that i was on the right track :)
>
> > i don't think that that would be a good idea. see alternatives above.
>
> yeah, i was confusing myself a bit. i noticed that
> SimpleDbPersistenceManager.close and DbFileSystem.close close their
> connections, and somehow i had the impression that all of these
> components shared a single connection, so i was worried that i'd still
> have one component dropping the connection for all the others. but now
> i realize that each of these components maintains its own connection
> and that i was scaring myself for nothing ;)
>
> by the way, a colleague asked yesterday if there would be any benefit
> to using connection pooling for these components. i assume that you'd
> have implemented them with pooling from the get-go if that had been
> the appropriate thing to do. is there any reasoning worth sharing in
> that regard?
one reason are the prepared statements that are associated with a connection.
another reason are transactions, i.e. connection needs to be the same during
the scope of a jcr transaction.
last but not least i wanted to keep the implementation simple.
cheers
stefan
>
> thanks!
>
Re: using one db for all filesystems and pms
Posted by Brian Moseley <bc...@osafoundation.org>.
On 1/19/06, Stefan Guggisberg <st...@gmail.com> wrote:
> 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.
this is what i was slowly convincing myself to try, so i'm glad to
hear that i was on the right track :)
> i don't think that that would be a good idea. see alternatives above.
yeah, i was confusing myself a bit. i noticed that
SimpleDbPersistenceManager.close and DbFileSystem.close close their
connections, and somehow i had the impression that all of these
components shared a single connection, so i was worried that i'd still
have one component dropping the connection for all the others. but now
i realize that each of these components maintains its own connection
and that i was scaring myself for nothing ;)
by the way, a colleague asked yesterday if there would be any benefit
to using connection pooling for these components. i assume that you'd
have implemented them with pooling from the get-go if that had been
the appropriate thing to do. is there any reasoning worth sharing in
that regard?
thanks!
Re: using one db for all filesystems and pms
Posted by Brian Moseley <bc...@osafoundation.org>.
On 1/25/06, Stefan Guggisberg <st...@gmail.com> wrote:
> i attached a repository.xml that stores everything in a single derby db.
>
> note that i only had to change *two* lines in the example repository.xml
> found in jackrabbit/src/main/config:
>
> i changed to "url" param of the Workspace PersistenceManager to:
> <param name="url" value="jdbc:derby:${rep.home}/db;create=true"/>
>
> i changed to "url" param of the Versioning PersistenceManager to:
> <param name="url" value="jdbc:derby:${rep.home}/db;create=true"/>
yeah, that is straightforward. my problems come when i use
DerbyFileSystems also. the first time i tried that i got an exception
when one of the components was trying to create its schema, so i
removed create=true from the urls and preloaded the complete schema
into the db. then i got exceptions at shutdown time because the first
component to close itself shut derby down as well. we talked about
that before, and your suggestion was to use SimpleDb* instead of the
derby variants and manage startup and shutdown of derby externally.
that's fine for my webapp which runs in a container, but i also have
command line tools for registering custom node types and importing
data, and i don't want them to have any specific knowledge of the
repository configuration or to have to manage the repository's
database. so basically i'm unable to use embedded derby with one
database for all five PMs and FSs unless i can figure out some other
way to shut down the embedded derby from within jackrabbit that is not
tied to the lifecycle of the PM and FS components but is guaranteed to
execute after they are all shut down. and there you have it - my whole
story :)
Re: using one db for all filesystems and pms
Posted by Stefan Guggisberg <st...@gmail.com>.
On 1/24/06, Brian Moseley <bc...@osafoundation.org> wrote:
> On 1/24/06, Giota Karadimitriou <Gi...@eurodyn.com> wrote:
> > For me at this point it would be best to use one db. I tried this with
> > embedded Derby and seems to work ok; I just wanted some extra opinion
> > just to verify I am on the right track:
>
> what does your repository.xml look like? i was never able to get it a
> one-db configuration to work with embedded derby.
>
i attached a repository.xml that stores everything in a single derby db.
note that i only had to change *two* lines in the example repository.xml
found in jackrabbit/src/main/config:
i changed to "url" param of the Workspace PersistenceManager to:
<param name="url" value="jdbc:derby:${rep.home}/db;create=true"/>
i changed to "url" param of the Versioning PersistenceManager to:
<param name="url" value="jdbc:derby:${rep.home}/db;create=true"/>
cheers
stefan
RE: using one db for all filesystems and pms
Posted by Giota Karadimitriou <Gi...@eurodyn.com>.
Just to add that since in the example below I do not use different
schemas there is no guarantee the data are not corrupted, even though
after running one test things look ok.
If I finally use Derby I will choose to go with the safe solution of
using multiple schemas and a separate Derby DB for versioning.
Giota
-----Original Message-----
From: Giota Karadimitriou [mailto:Giota.Karadimitriou@eurodyn.com]
Sent: Wednesday, January 25, 2006 11:43 AM
To: jackrabbit-dev@incubator.apache.org
Subject: RE: using one db for all filesystems and pms
Something weird is definitely taking place there because I also had my
share of failed efforts always having to do with cannot insert duplicate
key sth..
I managed to create a single db only when using one persistence manager
(SimpleDB..) and after hardcoding some of the paths. The repository.xml
in that case looks like that:
<Workspace name="${wsp.name}">
<FileSystem
class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${wsp.home}"/>
</FileSystem>
<PersistenceManager
class="org.apache.jackrabbit.core.state.db.SimpleDbPersistenceManager">
<param name="driver"
value="org.apache.derby.jdbc.EmbeddedDriver"/>
<param name="url"
value="jdbc:derby:${wsp.home}/db;create=true"/>
.
<param name="schema" value="derby"/>
<param name="schemaObjectPrefix" value="default_"/>
<param name="externalBLOBs" value="false"/>
</PersistenceManager>
.
</Workspace>
<Versioning rootPath="${rep.home}/versions">
<FileSystem
class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${rep.home}/versions"/>
</FileSystem>
<PersistenceManager
class="org.apache.jackrabbit.core.state.db.SimpleDbPersistenceManager">
<param name="driver"
value="org.apache.derby.jdbc.EmbeddedDriver"/>
<param name="url"
value="jdbc:derby:workspaces/db;create=true"/>
.
<param name="schema" value="derby"/>
<param name="schemaObjectPrefix" value="default_"/>
<param name="externalBLOBs" value="false"/>
</PersistenceManager>
</Versioning>
If for some reason the first (bold) ${wsp.home} turns to workspaces I
get the known exception for duplicate key.
Giota
-----Original Message-----
From: ixjonez@gmail.com [mailto:ixjonez@gmail.com] On Behalf Of Brian
Moseley
Sent: Tuesday, January 24, 2006 7:06 PM
To: jackrabbit-dev@incubator.apache.org
Subject: Re: using one db for all filesystems and pms
On 1/24/06, Giota Karadimitriou <Gi...@eurodyn.com> wrote:
> For me at this point it would be best to use one db. I tried this with
> embedded Derby and seems to work ok; I just wanted some extra opinion
> just to verify I am on the right track:
what does your repository.xml look like? i was never able to get it a
one-db configuration to work with embedded derby.
RE: using one db for all filesystems and pms
Posted by Giota Karadimitriou <Gi...@eurodyn.com>.
Something weird is definitely taking place there because I also had my
share of failed efforts always having to do with cannot insert duplicate
key sth..
I managed to create a single db only when using one persistence manager
(SimpleDB..) and after hardcoding some of the paths. The repository.xml
in that case looks like that:
<Workspace name="${wsp.name}">
<FileSystem
class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${wsp.home}"/>
</FileSystem>
<PersistenceManager
class="org.apache.jackrabbit.core.state.db.SimpleDbPersistenceManager">
<param name="driver"
value="org.apache.derby.jdbc.EmbeddedDriver"/>
<param name="url"
value="jdbc:derby:${wsp.home}/db;create=true"/>
.
<param name="schema" value="derby"/>
<param name="schemaObjectPrefix" value="default_"/>
<param name="externalBLOBs" value="false"/>
</PersistenceManager>
.
</Workspace>
<Versioning rootPath="${rep.home}/versions">
<FileSystem
class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
<param name="path" value="${rep.home}/versions"/>
</FileSystem>
<PersistenceManager
class="org.apache.jackrabbit.core.state.db.SimpleDbPersistenceManager">
<param name="driver"
value="org.apache.derby.jdbc.EmbeddedDriver"/>
<param name="url"
value="jdbc:derby:workspaces/db;create=true"/>
.
<param name="schema" value="derby"/>
<param name="schemaObjectPrefix" value="default_"/>
<param name="externalBLOBs" value="false"/>
</PersistenceManager>
</Versioning>
If for some reason the first (bold) ${wsp.home} turns to workspaces I
get the known exception for duplicate key.
Giota
-----Original Message-----
From: ixjonez@gmail.com [mailto:ixjonez@gmail.com] On Behalf Of Brian
Moseley
Sent: Tuesday, January 24, 2006 7:06 PM
To: jackrabbit-dev@incubator.apache.org
Subject: Re: using one db for all filesystems and pms
On 1/24/06, Giota Karadimitriou <Gi...@eurodyn.com> wrote:
> For me at this point it would be best to use one db. I tried this with
> embedded Derby and seems to work ok; I just wanted some extra opinion
> just to verify I am on the right track:
what does your repository.xml look like? i was never able to get it a
one-db configuration to work with embedded derby.
Re: using one db for all filesystems and pms
Posted by Brian Moseley <bc...@osafoundation.org>.
On 1/24/06, Giota Karadimitriou <Gi...@eurodyn.com> wrote:
> For me at this point it would be best to use one db. I tried this with
> embedded Derby and seems to work ok; I just wanted some extra opinion
> just to verify I am on the right track:
what does your repository.xml look like? i was never able to get it a
one-db configuration to work with embedded derby.
Re: using one db for all filesystems and pms
Posted by Stefan Guggisberg <st...@gmail.com>.
On 1/24/06, Giota Karadimitriou <Gi...@eurodyn.com> wrote:
> For me at this point it would be best to use one db. I tried this with
> embedded Derby and seems to work ok; I just wanted some extra opinion
> just to verify I am on the right track:
>
> If I use one database instance for all workspaces + versioning, can
> there be any serious problems like for example the data of the second
> workspace to
> overlap with the data of the first workspace etc?
there's no overlap or conflict if the workspace and versioning persistence
managers are configured properly. the 'schemaObjectPrefix' configuration
parameter is used to distinguish each workspaces schema objects.
e.g. the 'default' workspace uses a table 'default_node', the 'foo'
workspace uses a table 'foo_node' etc.
cheers
stefan
>
> seems not but thought to get a second opinion...
>
> regards
> Giota
>
>
> -----Original Message-----
> From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
> Sent: Monday, January 23, 2006 4:18 PM
> To: jackrabbit-dev@incubator.apache.org
> Subject: Re: using one db for all filesystems and pms
>
> On 1/23/06, Giota Karadimitriou <Gi...@eurodyn.com> wrote:
> > 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.
>
> the current setup (separate db's rather than one db) has been an
> arbitrary
> choice. you have to try out what works best for you.
>
> cheers
> stefan
>
> >
> > Regards
> > Giota
> >
> > -----Original Message-----
> > From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
> > Sent: Monday, January 23, 2006 3:41 PM
> > To: jackrabbit-dev@incubator.apache.org
> > Subject: Re: using one db for all filesystems and pms
> >
> > On 1/20/06, Giota Karadimitriou <Gi...@eurodyn.com>
> 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: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 <bc...@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
> > >
> > > >
> > >
> > >
> >
> >
>
>
RE: using one db for all filesystems and pms
Posted by Giota Karadimitriou <Gi...@eurodyn.com>.
For me at this point it would be best to use one db. I tried this with
embedded Derby and seems to work ok; I just wanted some extra opinion
just to verify I am on the right track:
If I use one database instance for all workspaces + versioning, can
there be any serious problems like for example the data of the second
workspace to
overlap with the data of the first workspace etc?
seems not but thought to get a second opinion...
regards
Giota
-----Original Message-----
From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
Sent: Monday, January 23, 2006 4:18 PM
To: jackrabbit-dev@incubator.apache.org
Subject: Re: using one db for all filesystems and pms
On 1/23/06, Giota Karadimitriou <Gi...@eurodyn.com> wrote:
> 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.
the current setup (separate db's rather than one db) has been an
arbitrary
choice. you have to try out what works best for you.
cheers
stefan
>
> Regards
> Giota
>
> -----Original Message-----
> From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
> Sent: Monday, January 23, 2006 3:41 PM
> To: jackrabbit-dev@incubator.apache.org
> Subject: Re: using one db for all filesystems and pms
>
> On 1/20/06, Giota Karadimitriou <Gi...@eurodyn.com>
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: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 <bc...@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
> >
> > >
> >
> >
>
>
Re: using one db for all filesystems and pms
Posted by Stefan Guggisberg <st...@gmail.com>.
On 1/23/06, Giota Karadimitriou <Gi...@eurodyn.com> wrote:
> 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.
the current setup (separate db's rather than one db) has been an arbitrary
choice. you have to try out what works best for you.
cheers
stefan
>
> Regards
> Giota
>
> -----Original Message-----
> From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
> Sent: Monday, January 23, 2006 3:41 PM
> To: jackrabbit-dev@incubator.apache.org
> Subject: Re: using one db for all filesystems and pms
>
> On 1/20/06, Giota Karadimitriou <Gi...@eurodyn.com> 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: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 <bc...@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
> >
> > >
> >
> >
>
>
RE: using one db for all filesystems and pms
Posted by Giota Karadimitriou <Gi...@eurodyn.com>.
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:stefan.guggisberg@gmail.com]
Sent: Monday, January 23, 2006 3:41 PM
To: jackrabbit-dev@incubator.apache.org
Subject: Re: using one db for all filesystems and pms
On 1/20/06, Giota Karadimitriou <Gi...@eurodyn.com> 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: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 <bc...@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
>
> >
>
>
Re: using one db for all filesystems and pms
Posted by Stefan Guggisberg <st...@gmail.com>.
On 1/20/06, Giota Karadimitriou <Gi...@eurodyn.com> 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: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 <bc...@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
>
> >
>
>
RE: using one db for all filesystems and pms
Posted by Giota Karadimitriou <Gi...@eurodyn.com>.
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 <bc...@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
>
Re: using one db for all filesystems and pms
Posted by Stefan Guggisberg <st...@gmail.com>.
On 1/19/06, Brian Moseley <bc...@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/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
>