Re: NGP: Prototyping

2007-11-15 Thread Thomas Mueller
Hi,

A few remarks about the current NGP prototype:

java.nio.ByteBuffer (FileJournal / MediumRecord)
Just curious, did you run some tests, is it faster than using
RandomAccessFile.read?

FileChannel.map
My experience with memory mapped files is: it is fast, but
problematic. The biggest problem (for me) is: there is no way to unmap
a file. That means it is not possible to truncate, rename, or delete a
file that was once mapped. See:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4724038

Journal:
A record is never modified or removed once it has been added to a
journal.. I agree, if there is a mechanism to removing old journal
files.

Thomas


[jira] Updated: (JCR-1043) Package names for spring project do not match update ocm packages

2007-11-15 Thread Padraic Hannon (JIRA)

 [ 
https://issues.apache.org/jira/browse/JCR-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Padraic Hannon updated JCR-1043:


Attachment: spring.patch

Here is a patch based on the latest version of the ocm-mapping project.

 Package names for spring project do not match update ocm packages
 -

 Key: JCR-1043
 URL: https://issues.apache.org/jira/browse/JCR-1043
 Project: Jackrabbit
  Issue Type: Bug
  Components: jcr-mapping
Affects Versions: 1.3
 Environment: All environments
Reporter: Padraic Hannon
Assignee: Christophe Lombart
Priority: Blocker
 Attachments: spring.patch


 The spring package and tests reference the old graffitto package naming 
 scheme.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (JCR-1043) Package names for spring project do not match update ocm packages

2007-11-15 Thread Padraic Hannon (JIRA)

 [ 
https://issues.apache.org/jira/browse/JCR-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Padraic Hannon updated JCR-1043:


Attachment: (was: spring.tar.gz)

 Package names for spring project do not match update ocm packages
 -

 Key: JCR-1043
 URL: https://issues.apache.org/jira/browse/JCR-1043
 Project: Jackrabbit
  Issue Type: Bug
  Components: jcr-mapping
Affects Versions: 1.3
 Environment: All environments
Reporter: Padraic Hannon
Assignee: Christophe Lombart
Priority: Blocker
 Attachments: spring.patch


 The spring package and tests reference the old graffitto package naming 
 scheme.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (JCR-1067) Referenced beans in an object graph should be persisted by the ocm automatically

2007-11-15 Thread Padraic Hannon (JIRA)

[ 
https://issues.apache.org/jira/browse/JCR-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542817
 ] 

Padraic Hannon commented on JCR-1067:
-

Should I create new converters? We are starting to more actively use OCM and we 
feel this is an important feature to have.

 Referenced beans in an object graph should be persisted by the ocm 
 automatically
 

 Key: JCR-1067
 URL: https://issues.apache.org/jira/browse/JCR-1067
 Project: Jackrabbit
  Issue Type: Improvement
  Components: jcr-mapping
Affects Versions: 1.3.1
Reporter: Padraic Hannon
 Attachments: BeanReferenceCollectionConverterImpl.diff, 
 ReferenceBeanConverterImpl.diff


 Currently the BeanReferenceCollectionConverter and ReferenceBeanConverter 
 classes only persist the UUID of the referenced object. There should either 
 be new converter classes that cascade down the object graph to ensure all 
 referenced items are created or updated, or the existing ones should be 
 updated to cascade. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (JCR-1043) Package names for spring project do not match update ocm packages

2007-11-15 Thread Padraic Hannon (JIRA)

[ 
https://issues.apache.org/jira/browse/JCR-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542874
 ] 

Padraic Hannon commented on JCR-1043:
-

I was about to make a jira ticket for that as well, I already started moving to 
maven 2 and will make sure yo upgrade to the newest spring.

Pih
--
Not sent from my iPhone



 Package names for spring project do not match update ocm packages
 -

 Key: JCR-1043
 URL: https://issues.apache.org/jira/browse/JCR-1043
 Project: Jackrabbit
  Issue Type: Bug
  Components: jcr-mapping
Affects Versions: 1.3
 Environment: All environments
Reporter: Padraic Hannon
Assignee: Christophe Lombart
Priority: Blocker
 Attachments: spring.patch


 The spring package and tests reference the old graffitto package naming 
 scheme.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: NGP: Prototyping

2007-11-15 Thread Jukka Zitting
Hi,

On Nov 15, 2007 11:07 AM, Thomas Mueller [EMAIL PROTECTED] wrote:
 A few remarks about the current NGP prototype:

 java.nio.ByteBuffer (FileJournal / MediumRecord)
 Just curious, did you run some tests, is it faster than using
 RandomAccessFile.read?

I'm planning to... It would be really nice to map the entire journal
file (or the part that already exists when a repository is started)
into memory for direct access. In theory this should reduce the amount
of copying taking place, but it's still unclear whether that happens
in practice.

 FileChannel.map
 My experience with memory mapped files is: it is fast, but
 problematic. The biggest problem (for me) is: there is no way to unmap
 a file. That means it is not possible to truncate, rename, or delete a
 file that was once mapped. See:
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4724038

 Journal:
 A record is never modified or removed once it has been added to a
 journal.. I agree, if there is a mechanism to removing old journal
 files.

The way I see it, during normal operation we only need to be able to
append data to the file, so this shouldn't be a problem. At some
points the journal file needs to be vacuumed to save space, but that
operation would typically produce a new file that's then used to
replace the old journal. I'm not yet sure how often and at which
points such vacuuming needs to take place.

Also, I have an experimental C version of the journal and tree code.
The idea behind that is possibly to implement a mod_dav module to
enable direct WebDAV access to the tree structure stored in the
journal. The C implementation could also eventually become a highly
optimized JNI backend for an NGP implementation, in which case we'd
also have much more control over memory mapping (of course at the
expense of operating system dependencies).

BR,

Jukka Zitting


Adding XML DB Persistence Manager

2007-11-15 Thread Amir . Rafique

Hello Mates

I am new to jackrabbit world. I want to implement an XML DB persistence
manager which will store all of my repository data in Sedna DB (XML DB).
Can any one help on this by providing some info / tutorial about JackRabbit
Persistence manager layer / life cycle etc

Thanks in advance

Regards
~Amir Rafique


DISCLAIMER: This e-mail and any file transmitted with it is confidential and 
intended solely for the use of the addressee. If you are not the intended 
recipient, you are notified that disclosing, copying, distributing or taking 
any action regarding the contents of this information is strictly prohibited. 
If you have received this email in error, please return the original to the 
sender and destroy the same immediately. Any views or opinions presented in 
this email are solely those of the author and do not necessarily represent 
those of the company.
WARNING: The recipient should check this email and any attachment for the 
presence of viruses. Although the company has taken reasonable precautions to 
ensure no viruses are present in this email, the company does not accept 
responsibility for any loss or damage arising from the use of this email or 
attachment.