On 1/19/06, Brian Moseley <[EMAIL PROTECTED]> wrote: > On 1/19/06, Stefan Guggisberg <[EMAIL PROTECTED]> 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! >
