jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: using one db for all filesystems and pms
Date Thu, 19 Jan 2006 15:58:36 GMT
On 1/19/06, Brian Moseley <bcm@osafoundation.org> wrote:
> On 1/19/06, Stefan Guggisberg <stefan.guggisberg@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!
>

Mime
View raw message