jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: jackrabbit & clustering
Date Fri, 09 Jun 2006 14:41:20 GMT
Giota Karadimitriou wrote:
> In my previous email, I wrote the scenario that I try to follow
> regarding clustering; however I feel I am really at zero once again so
> could anybody provide me with some conceptual help regarding clustering
> aspects because I feel I need to understand the jackrabbit model a lot
> more in order to achieve sth:
>  
> 1)       If someone wanted to share states where would it be the best
> place to do it in regards to 
> beginUpdate().end() statement?
>  
> a)       Inside end(), before downgrading to read lock
> b)       Inside end() after downgrading to read lock and before
> events.dispatch

I'd say the states need to be distributed while holding the write lock. 
otherwise another cluster node may see inconsistent data.

> 2)       a) added states: do I need to propagate them or not (will the
> second cluster node find them eventually from the database and upload
> them into shsim2.cache either way?)

it depends, if you also want to trigger observation you have to 
propagate added states too. otherwise you are probably fine. but I'm not 
sure if there are other implications...

> c)       modified states; what I do is: if they are non-virtual and they
> exist on shism2.cache I just empty them from shsim2.cache, for virtual
> states, I copy from shism1 and notify

why isn't the handling the same for all states?

> d)       deleted states; what I do is: if they are non-virtual and they
> exist on shsim2.cache I just empty them from shsim2.cache, otherwise for
> virtual states, I just notify

again, why do you have separate handling for virtual and non-virtual 
states? shouldn't this be the same for both: notify?

> 3) I put a print statement "acquiring write lock" when acquiring write
> lock in SharedItemStateManager, I observed it's being print twice; why
> is that since SharedItemStateManager persists changes (to the database)
> only once?

hmmm, don't know. do you have a stacktrace with the log message? that 
probably helps.

> 3)       Distributed read locks; do you think they are necessary ?

now that you mention it... I think you should be just fine without them. 
I don't see a reason right now why you need them...

> 4)       To propagate the states I call an EJB from our application
> which connects to the SharedItemStateManager of the other node 
>  
> using 
>  
> RepositoryImpl repImpl = 
>             ((JCARepositoryHandle) repository).getRepositoryImpl();
>         SharedItemStateManager sism =
>             repImpl.getWorkspaceStateManager("default");
>  
> This is a terrible approach since I added a 
>  
> -public Repository getRepositoryImpl()  method in JCARepositoryHandle
>  
> -and I made RepositoryImpl.getWorkspaceStateManager public also
>  
> but I could think of no other way to retrieve access the
> sharedItemstatemanager of the other cluster node.
> I know that shared item state manager is supposed not to be visible but
> I must make it visible in order to share the states.
>  
> Is there some easier way?

well, I guess that's currently the only 'way'. Jackrabbit as it is right 
now just does not provide access to the SharedISM because it is 
considered internal.

> 5)       What additional things will be needed for "versioning"?

I assume it is similar to regular workspace content. at its bottom there 
is a SharedISM as well. But I don't know the details there...

> 6)       Connections seem to be exhausted after a while; why could that
> be?

do you mean connections that is used by the persistence managers?

regards
  marcel

Mime
View raw message