1

In a few months I'm going to have to horizontally partition my application. There are certain services within my application which need loads of CPU and memory, and for scaleability I'm going to want to shard it across multiple JVMs.

I have an EAR that encapsulates the services that I need to partition. When I do this clients of the services (such as the UI) will need to be able to address a particular instance of the service. For example, lets say I have a service named Account, but I actually have 3 instances of that service running in three different JVMs (but all in the same Java EE domain). Assuming I have a Service Locator that can map from an account ID to a particular VM, how would I access the EJBs that can service that particular account?

A potential solution I can see is to take advantage of the JNDI name that the application container gives to the EJBs in separate applications. If I deploy the module three different times with different names, I can do JNDI lookups to get to them:

java:global/AccountServer1/AccountFacade

java:global/AccountServer2/AccountFacade

java:global/AccountServer3/AccountFacade

In order for this to work, I could never use dependency injection to get to an AccountFacade, I would have to use AccountLocator EJB capable of taking an AccountID and mapping it to one of the Account applications. If I wanted to get tricky, I could probably implement a "Local" account facade that did the lookup transparently assuming that the arguments to the methods could identify which server to use...

Is this approach workable? Are there better alternatives?

Royce
  • 532
  • 3
  • 11

1 Answers1

0

You can take a look at Hibernate Shards as a blueprint for your architecture or use the framework directly. In short, they hide sharding behind, Session interface (EntityManager in case of JPA).

Konstantin Solomatov
  • 10,252
  • 8
  • 58
  • 88