jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Miro Walker" <miro.wal...@oyster.com>
Subject RE: [Jackrabbit Wiki] Update of "PersistenceManagerFAQ" by edgarpoce
Date Fri, 10 Jun 2005 09:32:50 GMT
Serge,

Well, if it's any help in terms of motivation, I currently have a client
who is interested in adopting jackrabbit as a repository, but has put as
a must-have requirement support for an RDBMS back-end, so from the
perspective of this project it's an essential component of the
repository. The rationale is that solutions to issues of transactional
integrity, mirroring and fail-over are thoroughly proven in the RDBMS
world and have a long history - from a client perspective, any other
approaches remain still too unproven to be relied upon. 

Regards,

Miro

-----Original Message-----
From: Serge Huber [mailto:shuber2@jahia.com] 
Sent: 09 June 2005 11:36
To: jackrabbit-dev@incubator.apache.org
Subject: Re: [Jackrabbit Wiki] Update of "PersistenceManagerFAQ" by
edgarpoce


Ok thanks guys for the positive feedback. I must say I was beginning to 
wonder if I should continue spending my time on it or not, but it looks 
like there is some interest so I will keep on. As I have said I have a 
lot of other projects going on at work and I'm always a little behind on

the latest and greatest in the JCR, but I do like this JSR so in any 
form I want to stay involved.

Regards,
  Serge Huber.

Simon Gash wrote:

>Serge, I know clients who won't be interested in any other option but
>the ORM PM. There are loads of reasons why this type of PM offers a
good
>solution. The important point is that there will never be a one size
>fits all PM solution hence a pluggable strategy (ooops sorry stefan...)
>is an excellent idea.
>
>Come on Madhu give the guy some positive feedback !!!
>
>Anyway, as soon as you are happy with it we'll be downloading it and
>running it...surely that must rate as some positive karma ;)
>
>
>Simon
>
>-----Original Message-----
>From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com] 
>Sent: 09 June 2005 11:11
>To: jackrabbit-dev@incubator.apache.org
>Subject: Re: [Jackrabbit Wiki] Update of "PersistenceManagerFAQ" by
>edgarpoce
>
>On 6/9/05, Serge Huber <shuber2@jahia.com> wrote:
>  
>
>>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 ?
>>
>>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 databases and sorts but that's also a question of personal
>taste i guess. 
>i don't have a problem with ORM PM in contrib and there seems to be
>interest in it.
>
>cheers
>stefan
>
>  
>
>>Regards,
>>  Serge Huber.
>>
>>Apache Wiki wrote:
>>
>>    
>>
>>>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:
>>>= PersistenceManager(PM) FAQ =
>>>The responses were mainly gathered from the jackrabbit mailing list.
>>>
>>>=== What's a PM? ===
>>>The PM is an *internal* Jackrabbit component that handle the
>>>      
>>>
>persistent storage of content nodes and properties. Each workspace of a
>Jackrabbit content repository uses a separate persistence manager to
>store the content in that workspace. Also the Jackrabbit version
handler
>uses a separate persistence manager. The PM sits at the very bottom
>layer in jackrabbits system architecture.
>  
>
>>>Reliability, integrity and performance of the PM are *crucial* to the
>>>      
>>>
>overall 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 references e.g.).
>  
>
>>>=== What's the PM responsibility? === The PM interface was never 
>>>intended as being a general SPI that you could implement in order to
>>>      
>>>
>integrate external datasources with proprietary formats (e.g. a
>customers database). the reason why we abstracted the PM interface 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).
>  
>
>>>=== How smart should be a PM? ===
>>>A PM should not be 'intelligent', it should not 'interpret' the data.
>>>      
>>>
>The only thing it should care about is to efficiently, consistently and
>reliably store and read the data encapsulated in the passed nodeState &
>propertyState objects. Though it might be feasible to write a custom
>persistence manager 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 certainly would not recommend it.
>  
>
>>>=== What about ORM-backed PMs? ===
>>>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.
>  
>
>>>=== What combination of FS and PM is the best choice? === It depends 
>>>on your priorities. If you want to store your data in an accessible
>>>      
>>>
>format (just in case ;), you might want to try XML PM +
localFileSystem.
>If you use windows and performance is a must, you might want to try
>objectPersistenceManager + cqfs.
>  
>
>>>=== Which are the current options? What are the status, pros and cons
>>>      
>>>
>
>  
>
>>>of each implementation? ===
>>>
>>>=== objectPersistenceManager ===
>>>* 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
>>>
>>>=== xml persistenceManager ===
>>>* 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
>>>
>>>=== ORM persistenceManagers ===
>>>* 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
>>>      
>>>
>synchronized.
>  
>
>>>=== localFileSystem: ===
>>>* Status: mature
>>>* Slow on window boxes
>>>
>>>=== CQFS file system ===
>>>* Status: mature
>>>* Mysterious configuration options ;)
>>>* Mysterious proprietary binary format ;)
>>>* fast on windows
>>>* license issue, it's proprietary
>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>Come visit us at:
> 
>Internet World 2005. June 14 - 16, Earls Court, Stand # A60
>
>Government Computing Expo. June 21 & 22, Earls Court, Stand # 804
>
>SOCITM Annual Event. October 16 - 18 Brighton Hotel, Stand # 28
>GOSS - Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and
88th in the Deloitte Technology Fast 500 EMEA. 
>
>This email contains proprietary information, some or all of which may
be legally privileged. It is for the intended recipient only. If an
addressing or transmission error has misdirected this email, please
notify the author by replying to this email. If you are not the intended
recipient you may not use, disclose, distribute, copy, print or rely on
this email. 
>
> 
>
>Email transmission cannot be guaranteed to be secure or error free, as
information may be intercepted, corrupted, lost, destroyed, arrive late
or incomplete or contain viruses. This email and any files attached to
it have been checked with virus detection software before transmission.
You should nonetheless carry out your own virus check before opening any
attachment. GOSS Interactive Ltd accepts no liability for any loss or
damage that may be caused by software viruses.
> 
>
>
>  
>


_________________________________________________________________________________________________________________________
Internet communications are not secure and therefore Oyster Partners Ltd does not accept legal
responsibility for the contents of this message. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Oyster Partners Ltd.

Mime
View raw message