hi edgar On 3/18/06, Edgar Poce <[EMAIL PROTECTED]> wrote: > Hi to all, > > more thoughts on database persistence ... > > It seems having a jdbc based persistence manager as the default > implementation misleads users, new and not so new users often think > that jackrabbit will benefit from rdbms features and analyze > jackrabbit internals taking into account j2ee best practices. > > Keeping simple the SimpleDBPersistenceManager is a good option not > only for the sake of simplicity, but also because other approaches are > discouraged due to design decisions. As Stefan pointed a few times > jackrabbit is designed to stand in its own right. It means that it's > not designed to leverage any persistence storage engine, rdbms > included. > > The fact derby is the default PM doesn't mean it's the best option, > there's overhead related to sql parsing and too many unused features. > It took me a while to understand it :), but I agree that for now the > best option is a simple and transactional btree implementation, as > Stefan has been pointing for a long time. Something like > http://jdbm.sourceforge.net/ would probably be a better fit. Stefan, > WDYT?. Is it worth to give it a try?
i've never took a closer look at jdbm but it's certainly something worth investigating. > > Since questions about leveraging rdbms capabilities arises in the > Mailing list all the time, in case the comments above have any sense, > I suggest adding a few more entries to the faqs that make clear > Jackrabbit is not just a layer on top of a rdbms. WDYT? yes, i agree. cheers stefan > > e.g. > ---- > > I want to use jackrabbit in a j2ee environment and I want to use JNDi > to configure jdbc connections, how can I do it? > You can override the default implementation and get connections > through JNDI, but take into account that using a rdbms in server mode > is not the best option. Jackrabbit *is* a storage engine by itself. > > Does Jackrabbit leverage rdbms capabilities? > No, all Jackrabbit needs from a PersistenceManager implementation is a > simple transactional persistence mechanism that supports large > collections. A simple btree implementation suffice. > > What's the benefits of using a jdbc based PM implementation? > Only the rdbms administrative stuff, scheduled backups, etc. > > --- > > my 0,0002 cents, in case it worths that much ;) > edgar > > ps, congratulations to all. you are all doing a great job!! > > On 3/18/06, Jukka Zitting <[EMAIL PROTECTED]> wrote: > > Hi, > > > > On 3/18/06, Stefan Guggisberg <[EMAIL PROTECTED]> wrote: > > > 'Simple' also refers to use of a very simple data model instead of > > > a fully normalized schema or some object-relational mapping. > > > > Agreed. A different data model would require a fully separate PM class > > (like in the orm- or dbd- contribs). I believe the > > SimpleDbPersistenceManager data model is good for the current needs > > and pretty much orthogonal to the way the database connection is > > handled. > > > > > those best practices apply to j2ee applications. the point is that i don't > > > consider jackrabbit to be a j2ee application, jackrabbit is infrastructure > > > and has other requirements regarding its persistence layer than a > > > database application. > > > > Good point. In many cases Jackrabbit however lives in a J2EE > > environment and, as expressed in JCR-313, there are legitimate needs > > for using it within the constraints of existing database deployments. > > > > > note that write operations must occur within a single transaction, i.e. > > > you can't get a new connection for every write operation. > > > > Ah, good point. That pretty much downs my proposal. So, withdrawn for now. > > > > BR, > > > > Jukka Zitting > > > > -- > > Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] > > Software craftsmanship, JCR consulting, and Java development > > >
