jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Bingë <stuart.bi...@complinet.com>
Subject Recommended large-scale deployment & client access strategies
Date Fri, 08 May 2009 16:37:49 GMT
Hello list,

I've been looking around the interwebs for recommended deployment plans and 
client access guidelines for a Jackrabbit cluster and have come up somewhat 
short, both on the wiki and through Google. I was thinking the list would be a 
better place to ask for such information; I'm guessing quite a few of you are 
running JR in or near production and so have more experience in all this.

Our scenario is as follows:
We're currently prototyping JR as a content store, intended as a replacement 
for several poorly designed databases, in a bid to unify all our disparate 
content silos.

They way we're currently viewing JR though is effectively as a database 
replacement, so a tier in its own right. In production we'd end up having a 
cluster of JR instances (with a DB-backed repository) serving up the content 
as a data tier, then a series of application servers sitting as a distinct 
tier, talking JCR over JVM-RMI (i.e. via ClientRepositoryFactory and its 
associated classes).

The past couple of days we've been fighting with this scheme and hence RMI in 
order to get proper transactional session management working (we've been using 
Springmodules-JCR for this) and are about 90% there. However, this 
implementation still feels very wrong... Reading what little information is 
available it seems as though RMI is the Wrong Way To Do It.

Another potential route that we've come up with is to create a custom data 
wrapper around JR, so when we deploy JR we'd be deploying our own application 
with an embedded JR instance (still with the same DB-backed repository), and 
would then cluster this unit. This wrapper would allow us to use local JCA-
managed transactions and local JCR access in each clustered unit, and 
ultimately expose a more coarse data layer that is not tied to JCR as our own 
service, over whatever protocol we decide on. This layer would then form our 
data tier; on top of this we'd potentially have another application tier if we 
require a more coarse data service, but this is up for debate.

Looking through all the documentation I'm getting the impression that the JCR 
API was never intended to be used remotely as say the JDBC API is; it seems 
like Jackrabbit is not exactly the full data layer we've been treating it as, 
and is instead a component in such a full remotely-accessible data store that 
users are ultimately left to implement themselves.

I suppose there's not really a question in all the above, but I'd like to hear 
any thoughts that people may have on where we may be going wrong or how they 
are using Jackrabbit in similar circumstances more effectively. Essentially a 
"recommended usage guide" for large-scale remote content access. Any help 
would be greatly appreciated :-)

TIA,
--
Stuart Bingë

______________________________________________________________________

“Complinet Ltd is registered in England. Registered office at Vintners Place, 68 Upper Thames
Street, London EC4V 3BJ. Company number 3170722. VAT No. 749 324 021.
Complinet Inc is a corporation registered in Delaware, USA.”

This email has been scanned by the MessageLabs Email Security System.
Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message