cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple instances running against one repository?

martinbradford
Champ in-the-making
Champ in-the-making
Hi all,

We are building a bespoke application which is storing documents in an Alfresco repository through a purpose built user interface. The presentation layer of the application is being coded in JSP and we have successfully written pages which insert and retrieve documents via calls to the Web Service API. Initially I actually had the java embedded in the JSP and have now abstracted it out to Java Beans but still runnning within the context of the servlet container. It works ok, but it is a bit sluggish and I think this is mostly down to the fact that it is essentially stateless code and is repeatedly logging into the repository and back out again.

Is there anything to stop me implementing a server of my own in either an EJB container or possibly CORBA using the Apfresci foundation API but also having the Alfresco web client running in Tomcat at the same time against the same repository? That way, I can make my bespoke server stateful and cut out a lot of the latency. Initially, I assumed that there would be locking issues and conflicts, but on further reflection it seems like the web client must work in pretty much this way since it is running in a servlet container rather than a full apps server - am I wrong?

many thanks in advance

Martin
3 REPLIES 3

martinbradford
Champ in-the-making
Champ in-the-making
After some more reading, I think I may have gone some way towards answering my own question - what I am trying to do seems very similar to the "clustered repository" mentioned in the repository architecture section of the wiki - that seems to show multiple instances sharing a common file store and database.

There are references to the need to set up the transaction architecture properly, but I have not yet found the details… Has anyone got experience of setting this up?

Martin

alexeyg
Champ in-the-making
Champ in-the-making
Martin,

I am doing something similar to what you are talking about by pulling the Alfresco Repository from Alfresco Web Client ServletContext… Frankly I do not like the way it is currently set up… It feels ugly, but I needed a solution fast.   I will be looking into changing it soon…

To make same instances of classes of by Alfresco Web Client available in a different servlet context you need to make sure a shared classloader loads them.  You have to move stuff to achieve this:

from
\tomcat\webapps\alfresco\WEB-INF\classes
to
\tomcat\shared\classes

and from
\tomcat\webapps\alfresco\WEB-INF\lib
to
\tomcat\shared\lib

Also, you app has to specify crossContext="true" in the <context> element to be able to access Alfresco WC context.

Once all this is done you can pull Alfresco beans from the other context (this is inside of a servlet, so method getServletContext() is available:

      ServletContext alfrescoWebContext = getServletContext().getContext("/alfresco");

      WebApplicationContext alfrescoSpringContext = WebApplicationContextUtils.getRequiredWebApplicationContext(alfrescoWebContext);

      Repository repository = (Repository)alfrescoSpringContext.getBean("JCR.Repository");

      ServiceRegistry registry = (ServiceRegistry)alfrescoSpringContext.getBean(ServiceRegistry.SERVICE_REGISTRY);

etc…

Does anybody know of a better way to do this?  Thanks!

Good luck!

martinbradford
Champ in-the-making
Champ in-the-making
Alex,

that is very useful - I've never really taken the time to learn the finer details of the servlet engine to that level of detail!

The "better solution" would be to have the alfresco engine running in a more purpose built middle tier execution environemnt like an EJB server or Corba ORB and all applications including the web GUI share a single instance! When I saw that it was running in JBoss, that is what I was expecting… When I have the time, I may have a go at "Corba-izing" it - I don't see why it should be too difficult, but there are quite a lot of functions to expose and it would be fairly time-consuming…

Martin