Jin,
Before providing a direct answer , it is important to understand what is GigaSpaces.
GigaSpaces is a scale-out-application server. In includes In-Memory-Data-Grid (IMDG) , web server , messaging , security , high-availability , load-balancing , recovery , persistency and Interoperability services. This means you can host your business logic within GigaSpaces in the same manner you are doing it with JBoss. It is true that GigaSpaces is a not fully J2EE compatible app server (and there is a reason for this), but it includes most of what you will find with J2EE app server and many more capabilities that J2EE do not have that we found very important for the 21st century applications.
So before you will continue with the path you took - I would suggest you to consider the following:
1. Does my application relay on its data in a great manner? Do I need to access my IMDG in the most efficient manner , have the business logic close to the data and make these to act as one unified entity to fail and scale together?
Or
2. My application is not data intensive and I would like to have my IMDG located in a different process(s) (potentially on a different machine(s)) where the application and the IMDG scales and fail in different manner?
If your requirements are closer to the first option , I would suggest you to consider GigaSpaces as your application server to host and mange both the IMDG and the business logic. These will be encapsulated within what we call a processing unit. This is a spring based container hosted within SLA based container that scales , load-balanced and recovers in automatic manner.
If your requirements are closer to the second option , you should deploy the IMDG separately. In this case you might want to have some of the data close to the business logic by having a local cache or local view running at the app server client side. With this case , you can have JBoss as your application server or GigaSpaces as the application server where the business logic accessing a remote GigaSpaces container that host the IMDG.
The benefit of using GigaSpaces as the business logic container would be out of the box failover , scaling and self healing capabilities both for the data and the business logic components. For example: You could instruct GigaSpaces to run 10 instances of your business logic , no matter what will happen and scale these up to 20 instances in case you need more processing capacity - all this in a transparent manner. In case one of them would fail - GigaSpaces will start a new one on the fly.
See this video for a demo that illustrates what you can do with GigaSpaces as an application server:
04e.html">http://www.gigaspaces.com/tempfiles/webinar1/sgeIntegration/SGEIntegrationWithGigaSpacesXAP2008Q404e.html
See here more details about the SLA container I've mentioned:
http://www.gigaspaces.com/wiki/display/XAP66/ServiceGridProcessingUnitContainer
To answer your specific question - see this:
http://www.gigaspaces.com/wiki/display/XAP66/SpaceComponent#SpaceComponent-PrimaryBackupNotifications
If your business logic would have been deployed as a processing unit having its space collocated - you would not need to have this manual failover implemented yourself. You will get this out of the box.
A space running in a backup mode cannot be accessed by the business logic (remote or embedded). Once you will get the relevant event that the backup moved into primary mode, the business logic running within the other JBoss instance will be able to access the space.
Shay
Attachments
- gigaspacesFailover.vsd
- SpaceEventListener.java
- CacheHelper.java
- gsurls.properties
- pu.xml
- SpaceEventListener.java
- pu.xml
- SpaceEventMain.java
