From jackrabbit-dev-return-2285-apmail-incubator-jackrabbit-dev-archive=www.apache.org@incubator.apache.org Thu Jun 09 10:11:32 2005 Return-Path: Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org Received: (qmail 43874 invoked from network); 9 Jun 2005 10:11:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Jun 2005 10:11:32 -0000 Received: (qmail 87594 invoked by uid 500); 9 Jun 2005 10:11:30 -0000 Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jackrabbit-dev@incubator.apache.org Delivered-To: mailing list jackrabbit-dev@incubator.apache.org Received: (qmail 87540 invoked by uid 99); 9 Jun 2005 10:11:29 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of stefan.guggisberg@gmail.com designates 64.233.162.203 as permitted sender) Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.203) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 09 Jun 2005 03:11:26 -0700 Received: by zproxy.gmail.com with SMTP id 18so75413nzp for ; Thu, 09 Jun 2005 03:11:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=r9OWr6aFmDVqg2xAA5OCVyFqlP6eyFZ7zc6KXTXz2RXJdh0hAxoYK4OtCVNGhi2Qmuk6EOm0e0Y59Klk9i12YHyodVUuzsSDKsjrvol7dvy9EkSt6mxqHzvU9+MG8EMaIbFDFtj7sfNn/zdgfait1v1i5vNQXfySBnt0zGDCwpk= Received: by 10.36.115.1 with SMTP id n1mr269295nzc; Thu, 09 Jun 2005 03:11:14 -0700 (PDT) Received: by 10.36.81.3 with HTTP; Thu, 9 Jun 2005 03:11:14 -0700 (PDT) Message-ID: <90a8d1c0050609031111eb918b@mail.gmail.com> Date: Thu, 9 Jun 2005 12:11:14 +0200 From: Stefan Guggisberg Reply-To: Stefan Guggisberg To: jackrabbit-dev@incubator.apache.org Subject: Re: [Jackrabbit Wiki] Update of "PersistenceManagerFAQ" by edgarpoce In-Reply-To: <42A80D21.5020203@jahia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050609033414.22009.18679@ajax.apache.org> <42A80D21.5020203@jahia.com> X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 6/9/05, Serge Huber wrote: >=20 > Maybe it's me overreacting (I do have a lot of pressure at work right > now) but I'm getting a lot of negative karma about the ORM-PMs... If > they are not to most people tastes, maybe we should just remove them ? >=20 > For me it was mostly a way to propose quickly a new back-end to > Jackrabbit and get my hands dirty with the project. But if most people > on the project feel that they "add unnecessary complexity", or "are not > the right way to go", then maybe they should be removed ? don't worry, serge. i admit that i am not a huge fan of object relational= =20 databases and sorts but that's also a question of personal taste i guess.= =20 i don't have a problem with ORM PM in contrib and there seems to be interest in it. cheers stefan >=20 > Regards, > Serge Huber. >=20 > Apache Wiki wrote: >=20 > >Dear Wiki user, > > > >You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki"= for change notification. > > > >The following page has been changed by edgarpoce: > >http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ > > > >New page: > >=3D PersistenceManager(PM) FAQ =3D > >The responses were mainly gathered from the jackrabbit mailing list. > > > >=3D=3D=3D What's a PM? =3D=3D=3D > >The PM is an *internal* Jackrabbit component that handle the persistent = storage of content nodes and properties. Each workspace of a Jackrabbit con= tent repository uses a separate persistence manager to store the content in= that workspace. Also the Jackrabbit version handler uses a separate persis= tence manager. The PM sits at the very bottom layer in jackrabbits system a= rchitecture. > >Reliability, integrity and performance of the PM are *crucial* to the ov= erall stability & performance of the repository. If e.g. the data that a PM= is based upon is allowed to change through external means the integrity of= the repository would be at risk (think of referential integrity / node ref= erences e.g.). > > > >=3D=3D=3D What's the PM responsibility? =3D=3D=3D > >The PM interface was never intended as being a general SPI that you coul= d implement in order to integrate external datasources with proprietary for= mats (e.g. a customers database). the reason why we abstracted the PM inter= face was to leave room for future performance optimizations that would not= affect the rest of the implementation (e.g. by storing the raw data in a b= -tree based database instead of individual file). > > > >=3D=3D=3D How smart should be a PM? =3D=3D=3D > >A PM should not be 'intelligent', it should not 'interpret' the data. Th= e only thing it should care about is to efficiently, consistently and relia= bly store and read the data encapsulated in the passed nodeState & property= State objects. Though it might be feasible to write a custom persistence ma= nager to represent existing legacy data in a level-1 (read-only) repository= , I don't think the same is possible for a level-2 repository and i certain= ly would not recommend it. > > > >=3D=3D=3D What about ORM-backed PMs? =3D=3D=3D > >Persistence managers that store the item states in a complex schema are = not the right way to go. Keep it simple, e.g. the objectPersistenceManager = stores the item states as a raw stream of bytes. > > > >=3D=3D=3D What combination of FS and PM is the best choice? =3D=3D=3D > >It depends on your priorities. If you want to store your data in an acce= ssible format (just in case ;), you might want to try XML PM + localFileSys= tem. If you use windows and performance is a must, you might want to try ob= jectPersistenceManager + cqfs. > > > >=3D=3D=3D Which are the current options? What are the status, pros and c= ons of each implementation? =3D=3D=3D > > > >=3D=3D=3D objectPersistenceManager =3D=3D=3D > > * Status: mature > > * Simple > > * Not human readable > > * An inconsistency is hard to fix without a tool > > * easy to configure > > * Write operations are synchronized > > * if the jvm process is killed the repository might turn inconsistent > > * non transactional > > > >=3D=3D=3D xml persistenceManager =3D=3D=3D > > * Status: mature > > * not so simple but human readable > > * easy to configure > > * Write operations are synchronized > > * if the jvm process is killed the repository might turn inconsistent > > * non transactional > > > >=3D=3D=3D ORM persistenceManagers =3D=3D=3D > > * Status: work in progress > > * Unnecessary complexity > > * transactional > > * rdbms referencial integrity (possible, but not implemented yet) > > * not so easy to configure. > > * Multithreaded friendly. Write operations don't need to be synchronize= d. > > > >=3D=3D=3D localFileSystem: =3D=3D=3D > > * Status: mature > > * Slow on window boxes > > > >=3D=3D=3D CQFS file system =3D=3D=3D > > * Status: mature > > * Mysterious configuration options ;) > > * Mysterious proprietary binary format ;) > > * fast on windows > > * license issue, it's proprietary > > > > > > >=20 >