I'm currently working on a project that need to be dynamically scaled on demand according to the need.

My question is about scaling spring context. My web application has a classical multi module core (service, persistence, domain), which use use by client application (webapp, api).

The user end application could be clustered, database too, but I don't know how to proceed with spring context.

I plan to use Scala Akka actors on Spring service, but I can't be persuaded by the solution of using one context exposed by actors. All of the rest of the application is built with event driven techniques (Spring events are produced by the service layer).

I already built different webapps by user profile to scale according to user role (Eg. admin, enduser), however the only thing is Spring Context for business operations.

Question: Do I have to merge in one single context shared by all client applications or should I initialize one context per application?


  • Hi Zenithar, I feel this is a good question, however your thoughts seem a bit scattered. It is hard to understand what your question is and how the following diagram demonstrates a scalability problem.
    – maple_shaft
    Feb 11, 2013 at 15:19
  • Thanks, you have extracted the real question ! The diagram shows all scallable vectors, marked as a black dotted arrow. Only spring context does not have a scallable vector, because i don't know how to scale it !
    – Zenithar
    Feb 11, 2013 at 15:38
  • Posted on Spring forum : forum.springsource.org/…
    – Zenithar
    Feb 11, 2013 at 17:39
  • 1
    Maybe this could help ? forum.springframework.net/…
    – Zenithar
    Feb 11, 2013 at 22:49
  • Ahhh! Yes it does help, I wasn't aware that you were asking about the scalability of singleton entities in Spring. That answer is correct, as long as the singleton is stateless then there should not be a performance bottleneck here.
    – maple_shaft
    Feb 12, 2013 at 0:43

1 Answer 1


Its kinda hard to understand your diagrams, like is the front end section on the left part is the whole client application architecture?? and the right section is the server side? even though, it is, still I can't get to understand why you have the database and spring layer in the front end?is it a database uniquely local to each client application?

But to give my idea, the common trend in using Spring application context is making it as singleton meaning one spring context in the server side,thats the essence of it, or else you have already defy its purpose. The beans (e.g services) should be stateless so not to produce undesirable result that concurrency issues could results from more than one client requesting the same thing and would need to use the same beans/services. making them singleton of course is the ideal way to save memory and avoid the instance creation on demand and after using is just to be garbage collected. There will be no bottleneck but instead it would be actually faster cause the object is already loaded in the memory and each request will have its own heap when executing that object once called. So basically, singleton is faster and saves more memory.

  • It's not a "ui" frontend, but a frontend service. Clearly it's 2 distinct java process, frontend is an application server, and backend in a osgi container (apache karaf).
    – Zenithar
    Feb 22, 2013 at 22:48
  • Thanks for the clarifications! I haven't tried this kind of project yet, but you give me something to research about. =)
    – vine
    Jul 6, 2013 at 2:26
  • I'm not sure if this could help you, or probably you have already solved your issue, but lemme give you this link, blog.springsource.org/2007/06/11/…
    – vine
    Jul 6, 2013 at 2:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.