headers
Edgar Poce | 1 Sep 2005 05:35
Picon

Re: Is JDBC persistence manager supported by jackrabbit?

Hi vadim

Vadim Gritsenko wrote:
> Edgar,
> 
> Was trying to find more information following your references, but...
> 
>> [1] http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/1435
> 
> 
> Points to JIRA which states [1]:
> 
>    Comment by Edgar Poce [12/Jul/05 06:00 AM]
>    This kind of approach is discouraged by design
> 
> Can you please clarify your point? 

There are a couple of conversations in the archive about this. My point 
is that the PM contract is not suitable for mapping the itemstates into 
a relational database with a table design that breaks the ItemState into 
its constituent parts. The PM is intended to keep it simple, which means 
to store the itemstate as a whole without interpreting the data. See the 
jdbc pm under contrib.

The main problem to store the itemstates in a complex schema is the 
Collection handling. Since Collection fields changes are not logged into 
add/update/remove aware objects, all the elements in the Collection must 
be stored on each write call. It causes a hit on performance when 
handling collections with lots of elements, even with the simple PMs 
included in the core.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Marcel Reutegger | 1 Sep 2005 10:30
Picon

Re: Is JDBC persistence manager supported by jackrabbit?

Edgar Poce wrote:
> Vadim Gritsenko wrote:
>> PS Wiki page has incorrect statement:
>>
>>     XML PersistenceManager
>>       * Write operations are synchronized
>>
>> AFAICS, XML PM (unnecessarily) syncronizes all calls, including load() 
>> and exist() calls. 
> 
> Why incorrect? maybe incomplete...

The current implementation of the XML PM serializes all calls to 
store(), load() and exists(). This is because it operates on a 
non-transactional store (a FileSystem implementation). The FileSystem 
interface does not prevent dirty reads by its definition. Writing 
changes to a FileSystem that involves multiple files therefore *must* 
block reads, otherwise other sessions might see changes that are not yet 
completely committed.

The crucial point is PersistenceManager.store() which states:

Atomically saves the given set of changes.

I agree, that's not extremely descriptive ;) but it actually describes 
in one sentence what the PM has to guarantee.

>  > Does it mean FileSystem interface considered to be
> 
>> single threaded?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcel Reutegger | 1 Sep 2005 10:40
Picon

Re: Is JDBC persistence manager supported by jackrabbit?

Edgar Poce wrote:
> nafise hassani wrote:
> 
>> Hi Edgar
>> is there any problem with this issue that discarded
>> for inclusion?!!!
>> I mean that,I think this is a realy necessary feature
>> having jdbc persistance manager with jackrabbit why
>> this issue is discarded?
> 
> 
> It doesn't mean that any JDBPersistenceManager implementation is 
> discarded for inclusion, just the one proposed in JCR-91. You'll find 
> more detailed info in the archives[1] and in the wiki[2].

Stefan wrote a simple JDBC PM and committed it about two weeks ago. It 
does not use a complex schema, but rather sticks to the keep it simple 
rule. It contains sample configurations for MySQL and MSSQL.

As of today there is also support for Derby running as an embedded DB 
inside the same process as Jackrabbit.

All can be found under /contrib/db-persistence

regards
  marcel
Permalink | Reply | 0 comments |
headers
Tobias Strasser (JIRA | 1 Sep 2005 16:58
Picon
Favicon

Created: (JCR-205) Version.merge() corrupts repository

Version.merge() corrupts repository
-----------------------------------

         Key: JCR-205
         URL: http://issues.apache.org/jira/browse/JCR-205
     Project: Jackrabbit
        Type: Bug
  Components: versioning  
    Versions: 1.0    
 Reporter: Tobias Strasser
 Assigned to: Tobias Strasser 

Version.merge() corrupts repository. somehow the 'protected' flags of the nt:version nodetype is not
properly checked.
this happens due to a wrong test case that calls merge on a Version instead of a normal Node.
Permalink | Reply | 1 comment |
headers
Vadim Gritsenko | 1 Sep 2005 17:35

Re: Is JDBC persistence manager supported by jackrabbit?

Marcel Reutegger wrote:
> Edgar Poce wrote:
> 
>> Vadim Gritsenko wrote:
>>
>>> PS Wiki page has incorrect statement:
>>>
>>>     XML PersistenceManager
>>>       * Write operations are synchronized
>>>
>>> AFAICS, XML PM (unnecessarily) syncronizes all calls, including 
>>> load() and exist() calls. 
>>
>> Why incorrect? maybe incomplete...
> 
> The current implementation of the XML PM serializes all calls to 
> store(), load() and exists(). This is because it operates on a 
> non-transactional store (a FileSystem implementation). The FileSystem 
> interface does not prevent dirty reads by its definition. Writing 
> changes to a FileSystem that involves multiple files therefore *must* 
> block reads, otherwise other sessions might see changes that are not yet 
> completely committed.
> 
> The crucial point is PersistenceManager.store() which states:
> 
> Atomically saves the given set of changes.
> 
> I agree, that's not extremely descriptive ;) but it actually describes 
> in one sentence what the PM has to guarantee.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vadim Gritsenko | 1 Sep 2005 18:27

Re: Is JDBC persistence manager supported by jackrabbit?

Edgar Poce wrote:
> Hi vadim
> 
> Vadim Gritsenko wrote:
> 
>> Was trying to find more information following your references, but...
>>
>>> [1] http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/1435
>>
>> Points to JIRA which states [1]:
>>
>>    Comment by Edgar Poce [12/Jul/05 06:00 AM]
>>    This kind of approach is discouraged by design
>>
>> Can you please clarify your point? 
> 
> There are a couple of conversations in the archive about this. My point 
> is that the PM contract is not suitable for mapping the itemstates into 
> a relational database with a table design that breaks the ItemState into 
> its constituent parts.

Ok. Breaking ItemState into parts would tie storage layer to the ItemState 
structure - which would make it impossible to make changes in structure or 
hierarchy of ItemStates...

(Can one (potentially) have custom ItemState(s)?)

But - this makes me wonder why OJB PM and Hibernate PM are considered to be 
acceprable design even though they are implemented exactly in the same way - 
they break up ItemState into parts!?
(Continue reading)

Permalink | Reply | 6 comments |
headers
Eduardo Cruz | 1 Sep 2005 21:43
Picon

Maven error

I downloaded Jackrabbit, when I start maven I got the following log above 
!!! 

Eduardo
--------------------------------------

D:\MyDocuments\jackrabbit>maven
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.1-beta-1

DEPRECATED: the default goal should be specified in the <build> section of 
proje
ct.xml instead of maven.xml
build:start:

multiproject:install:
multiproject:projects-init:
[echo] Gathering project list
Starting the reactor...
Our processing order:
Jackrabbit Api
Jackrabbit Commons
Jackrabbit Core
+----------------------------------------
| Gathering project list Jackrabbit Api
| Memory: 2M/4M
+----------------------------------------
+----------------------------------------
(Continue reading)

Permalink | Reply | 2 comments |
headers
lists | 1 Sep 2005 23:20

NodeDefinition.getDefaultPrimaryType()

Hi,

I'm just wondering if I've found a bug with the above method, or if I 
just don't understand the way it should work.

I have the following content type defined (stripped down a little):

   <nodeType name="article" isMixin="false" 
hasOrderableChildNodes="true" primaryItemName="">
     <childNodeDefinition name="*" defaultPrimaryType="paragraph" 
autoCreated="false" mandatory="false" onParentVersion="COPY" 
protected="false" sameNameSiblings="true" />
     <childNodeDefinition name="*" defaultPrimaryType="attachment" 
autoCreated="false" mandatory="false" onParentVersion="COPY" 
protected="false" sameNameSiblings="true" />
   </nodeType>

When i run the following code (where nt is the article NodeType):

NodeDefinition[] defs = (NodeDefinition[]) nt.getChildNodeDefinitions();
for (int i=0; i<defs.length; i++) {
     System.out.println(defs[i].getDefaultPrimaryType().getName());
}

I get:
attachment
attachment

rather than:
paragraph
(Continue reading)

Permalink | Reply | 5 comments |
headers
lists | 2 Sep 2005 00:03

Re: NodeDefinition.getDefaultPrimaryType()

Got it. Needed:

         <requiredPrimaryTypes>
             <requiredPrimaryType>jcms:attachment</requiredPrimaryType>
         </requiredPrimaryTypes>

(Found builtin_nodetypes.xml!)

Digby

lists wrote:
> Hi,
> 
> I'm just wondering if I've found a bug with the above method, or if I 
> just don't understand the way it should work.
> 
> I have the following content type defined (stripped down a little):
> 
>   <nodeType name="article" isMixin="false" hasOrderableChildNodes="true" 
> primaryItemName="">
>     <childNodeDefinition name="*" defaultPrimaryType="paragraph" 
> autoCreated="false" mandatory="false" onParentVersion="COPY" 
> protected="false" sameNameSiblings="true" />
>     <childNodeDefinition name="*" defaultPrimaryType="attachment" 
> autoCreated="false" mandatory="false" onParentVersion="COPY" 
> protected="false" sameNameSiblings="true" />
>   </nodeType>
> 
> When i run the following code (where nt is the article NodeType):
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edgar Poce | 2 Sep 2005 06:49
Picon

Re: Is JDBC persistence manager supported by jackrabbit?

Vadim Gritsenko wrote:
> Ok. Breaking ItemState into parts would tie storage layer to the 
> ItemState structure - which would make it impossible to make changes in 
> structure or hierarchy of ItemStates...
> 
> (Can one (potentially) have custom ItemState(s)?)
> 
I think it's not possible without modifying some core classes.

> But - this makes me wonder why OJB PM and Hibernate PM are considered to 
> be acceprable design even though they are implemented exactly in the 
> same way - they break up ItemState into parts!?
> 
who said orm pm is a best practice example?

>> I think that the jcr-ext project under contrib might be a good 
>> starting point. Or, despite the PM is not intended to be a SPI, you 
>> can handle to plug your legacy data if you do it carefully.
> 
> 
> Thanks for pointers. Do you suggest to use decorators? I don't see 
> though how they could be plugged in into the jackrabbit...

I'm not sure about this, actually I haven't used jcr-ext yet, but I 
think that it could be used as a base for a level 1 impl with legacy 
data indenpendently from jackrabbit. See o.a.j.base package.
Another option would be to plug your legacy data with a custom PM.

regards
edgar
(Continue reading)

Permalink | Reply | 1 comment |

Gmane