jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Giota Karadimitriou" <Giota.Karadimitr...@eurodyn.com>
Subject RE: jackrabbit & clustering
Date Thu, 08 Jun 2006 17:28:15 GMT
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
(After end() the ChangeLog "shared" is cleared, so I guess it does not
make sense to share states after end() cause you've lost them)
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?)
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
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
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?
3)       Distributed read locks; do you think they are necessary ?
4)       To propagate the states I call an EJB from our application
which connects to the SharedItemStateManager of the other node 
RepositoryImpl repImpl = 
            ((JCARepositoryHandle) repository).getRepositoryImpl();
        SharedItemStateManager sism =
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?
5)       What additional things will be needed for "versioning"?
6)       Connections seem to be exhausted after a while; why could that
Thanks for any answers on those. 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message