[jira] Commented: (JCR-91) JDBCPersistenceManager contribution

["Edgar Poce (JIRA)" <ji...@apache.org>]

    [ http://issues.apache.org/jira/browse/JCR-91?page=comments#action_12314941 ] 

Edgar Poce commented on JCR-91:
-------------------------------

The more I know jackrabbit internals the more I see that this kind of approach is discouraged. I'll close this issue as "won't fix" unless anyone says anything to the contrary. Anyway, I'll make the changes needed to pass all the tests, it might be interesting to keep it in an experimental approach section, maybe in the wiki?.

> JDBCPersistenceManager contribution
> -----------------------------------
>
>          Key: JCR-91
>          URL: http://issues.apache.org/jira/browse/JCR-91
>      Project: Jackrabbit
>         Type: New Feature
>     Reporter: Edgar Poce
>     Priority: Minor
>  Attachments: 05-03-30-jdbc-persistence.zip, 05-04-06-jdbc-persistence.zip, 05-05-12-jdbc-persistence.zip
>
> A JDBC based PersistenceManager

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Commented: (JCR-91) JDBCPersistenceManager contribution

[Serge Huber <sh...@jahia.com>]

Hi Edgar,

Edgar Poce wrote:

>This kind of approach needs change aware objects for every collection contained 
>in the ItemState. Without this persisting a simple change like adding a single 
>child node might need hundreds of queries to the database, which would be 
>unbearably slow for any kind of app. 
>  
>
This is where an ORM layer would help, as it can track all changes to 
all objects.

Regards,
  Serge Huber

Re: [jira] Commented: (JCR-91) JDBCPersistenceManager contribution

[Edgar Poce <ed...@gmail.com>]

Hi serge
 
Jackrabbit is designed for storing the entire item state as a single
unit. Trying
to preserve the types or force referential integrity at database level
would need
to perform too many tasks at the PM level which inevitably will hit
performance.
That's the strength and weakness of the implementation I uploaded to JIRA, it 
preserves the type and forces referential integrity but it uses too
many queries
for any operation, either for reading or writing. 

This kind of approach needs change aware objects for every collection contained 
in the ItemState. Without this persisting a simple change like adding a single 
child node might need hundreds of queries to the database, which would be 
unbearably slow for any kind of app. 

> This brings me to beg the question : what is the recommended setup to
> use Jackrabbit in a clustering environment ?
AFAIR the conversation was closed without many clarifications about
the complexity of the task, maybe someone can shed light on this issue
to help the users to evaluate whether they can handle to code their
own implementations, which hopefully might be contributed and
eventually added to the project ;).

> - the JCR-RMI implementation should be able to talk to more than one node
> - adding another type of implementation such as JCR-RMI that would work
> with a cluster.
I can't follow you here. AFAIK jcr-rmi can already be used for
clustering. If the benchmarking initiative evolves you will be able to
test the performance of this strategy to check whether it fits your
needs.

kind regards,
edgar

Re: [jira] Commented: (JCR-91) JDBCPersistenceManager contribution

[Serge Huber <sh...@jahia.com>]

Edgar Poce (JIRA) wrote:

>    [ http://issues.apache.org/jira/browse/JCR-91?page=comments#action_12314941 ] 
>
>Edgar Poce commented on JCR-91:
>-------------------------------
>
>The more I know jackrabbit internals the more I see that this kind of approach is discouraged. I'll close this issue as "won't fix" unless anyone says anything to the contrary. Anyway, I'll make the changes needed to pass all the tests, it might be interesting to keep it in an experimental approach section, maybe in the wiki?.
>  
>
This brings me to beg the question : what is the recommended setup to 
use Jackrabbit in a clustering environment ? Since all the current 
implementations use file-based implementations, this would normally 
require that :

- the cache system must be cluster-aware (for example using OSCache with 
JGroups, or JBossCache, or the commercial Tangosol Coherence implementation)
- the file-system must be shared across the network and be locking-aware 
(which requires NFS).

or :

- the JCR-RMI implementation should be able to talk to more than one node
- adding another type of implementation such as JCR-RMI that would work 
with a cluster.

The database based PMs solve the problem of clustering the data by 
leaving the cluster handling to the JDBC drivers or the database 
implementation, a problem area that is quite well known and solved 
nowaways. The downside is that in terms of absolute performance there 
will always be a cost compared to the file-based PMs.

Did I miss something here ? Are there other options I didn't know of ?

Regards,
  Serge...