Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question


My tasks requires versioning of services and objects stored in space.

There can be situation that for some time one version of objects is inserted and then new version starts to be inserted. For those two versions of the same type of object I'd like to be able to configure the same service in two versions.

Is it possible? What about OSGi? Do you have any description of creation versioned services?

{quote}This thread was imported from the previous forum. For your reference, the original is [available here|http://forum.openspaces.org/thread.jspa?threadID=2804]{quote}

asked 2009-01-14 09:49:02 -0500

mnemos gravatar image

updated 2013-08-08 09:52:00 -0500

jaissefsfex gravatar image
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

See some basic info how to deal with this scenario below:

There are obviously more complex scenarios (such as ones that also involve a database and other external components) that need to be considered.

We provide ability to refresh an existing running Service using the Service reloading - see below more info:

GigaSpaces 7 will include some enhancements that will provide better user experience when upgrading the application Space Domain classes and Services.

Please send me a a note to shay at gigaspaces.com to provide you more detailed info.


answered 2009-01-15 09:32:30 -0500

shay hassidim gravatar image
edit flag offensive delete link more

Well, it's going to be a problem if your class hierarchy names don't change. It's the same problem Java would have with serialized classes where the serial definitions change.

If the serialized versions are compatible, or you can change the class definitions, it's easy: consider the following.

@SpaceClass public class BaseEntity { /* All fields here, including... */ Long versionId; @SpaceProperty public Long getVersionId() { return versionId; } }

@SpaceClass public class EntityVersion1 extends BaseEntity { EntityVersion1() { versionId=1L; } }

@SpaceClass public class EntityVersion2 extends BaseEntity { EntityVersion2() { versionId=1L; } }

With this structure, it's easy to maintain both versions of the BaseEntity in the space, querying based on versionId.

As far as OSGi is concerned, that's a different issue altogether. The answer is "yes, you can do that" but I'd have to have more information to tell you HOW.

answered 2009-01-14 14:05:04 -0500

jottinger gravatar image
edit flag offensive delete link more


Hi Joe,

This example you gave is quite smart way to solve the problem if cluster is not heavy loaded.

What about heavy loaded clusters? What about inserting new classes? In my case I have quite intensive data insertion from production site. Same time, types of data changes quite often as well as transformations done by services inside gigaspace. I'm thinking about OSGi to avoid need of stopping whole cluster for small changes.

With your example I can easily deploy new versions of services but not data-types. Right now to change one Hibernate-GigaSpace class I need to perform couple steps: stop feeder service, wait until all services finish transform data, switch off whole space, put new .jar files in place, change source database structure, switch on space, start feeder service. This makes it complicated and requires about half hour maintenance downtime.

I just started to read documentation of OSGi so I hope it can solve problem. From what I read, this technology should give me opportunity to just deploy new versions of classes and then just perform three steps: stop feeder service, change source database structure, start feeder service. This could be even improved to make feeder recognize if database structure changed and then do relational-to-object mapping with new version of classes.

I'm not sure what information you need.

Best regards, Mateusz

mnemos gravatar imagemnemos ( 2009-01-15 05:12:00 -0500 )edit

Mateusz, my solution would handle DATA versioning but not necessarily SERVICE versioning - although service versioning would be an easy trick once your messages were versioned. OSGi would simply include the request version in the message.

jottinger gravatar imagejottinger ( 2009-01-15 10:45:12 -0500 )edit


I need to test it. I'll do it tomorrow and let you know. But for curiosity, how you want to load new object versions?
I can think of redeploying service with updated jar on shared-lib directory but maybe you can advice something different.

mnemos gravatar imagemnemos ( 2009-01-15 10:51:46 -0500 )edit

7.0 would not need to have the shared-lib folder. The issues we had that led us to include the shared-lib have been resolved. See: http://www.gigaspaces.com/wiki/displa... .0

Milestone 3 (released on Jan 11, 2008) highlights: * Significantly improved classloading model - Putting classes in the shared-lib is no longer required. All processing unit libraries can now be put the lib directory and are now deployed to the processing unit's classloader and not the GSC-wide classloader. This enables better undeploy capabilities and eliminates class sharing between processing units


shay hassidim gravatar imageshay hassidim ( 2009-01-15 10:56:49 -0500 )edit

Oh, so what happen when I change .jar file with SpaceDomain classes. Will all services which uses classes from this jar reload classes?

mnemos gravatar imagemnemos ( 2009-01-15 11:20:05 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2009-01-14 09:49:02 -0500

Seen: 11 times

Last updated: Jan 15 '09