Transient Technology » gigaspaces

Unit Testing with a GigaSpaceFactoryBean

Martin Harris — Mon, 24 May 2010 10:29:26 +0000

I was talking to Shay Banon (Gigaspace Software Architect) he mentioned using GigaSpaceFactoryBean for writing gigaspace unit tests. I could find no examples on their site, although I concede it may be there somewhere. This shows post shows a simple example.

He also mentioned using the admin api to do full end to end integration testing. The admin api has huge potential as its able to control gigaspace containers, deploy into them and collect statistics. Its a powerful api.

This is documented on their site: http://www.gigaspaces.com/wiki/display/XAP7/Administration+and+Monitoring+API

Example unit test using GigaSpaceFactoryBean

The GigaSpaceFactoryBean does have javadoc: http://www.gigaspaces.com/docs/JavaDoc7.1/index.html. It can be used to provide a unit test with a gigaspace implementation for the duration of the test.

Step 1 Provide a spring definition of the GigaSpaceFactoryBean

Follow with other beans needed by the test. I.e service beans and their dependencies. Note that the space defined here will also need to be injected into services that need it. So you will need to use the same bean id. Careful separation of the spring files means you will be able to substitute a test space for the real one during testing.

Step 2 Write a unit test

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = "classpath:/somewhere/sometest-pu.xml")
public class SomeGigaspaceTest {

    @Resource
	private ServiceUnderTest myservice;

    @Resource
    private GigaSpace gigaSpace;

    @Before
    public void setUp() {

        // Setup anything you may wish to be
        // in the space before the test starts.
        this.gigaSpace.write(stuff);

    }

    @Test
    public void testSomething() throws InterruptedException {

        ImmutableSet dataFromGS = this.myservice.getStuff();
        assertFalse(dataFromGS.isEmpty());
        assertThat(dataFromGS.size(), is(100));

    }

Gigaspace API design – the GigaSpace write method

Martin Harris — Mon, 11 Jan 2010 05:00:00 +0000

Now don’t get me wrong, I like gigaspaces and I am not into bashing someones API for the sake of it. Take a look at the GigaSpace interface documented in javadoc: http://www.gigaspaces.com/docs/JavaDoc7.1/org/openspaces/core/GigaSpace.html Its time the API was cleaned up. Take the write method for instance:

 LeaseContext write(T entry,
                          long lease,
                          long timeout,
                          int modifiers)
                      throws DataAccessException

These are the things I dislike about it:

The long timeout and lease don’t have units declared. See my previous blog where I show a good way to supply durations.
The documentation is terrible, it does not mention what units the timeout are in, I had to navigate to LeaseContext to understand the lease, and find Lease.FOREVER. As I write this I still do not know how to set a maximum or minimum timeout. Perhaps 0, null? Not sure. What happens if you set a minus value?
The method has a mode in the form of modifiers. Modifiers is a bad name but I would rather delete it than change the name. The mode is not a great way to communicate what your method does, but this one is particularly bad because it can effect what might be returned and possibly the types of exception that might get thrown.

UpdateModifiers.UPDATE_OR_WRITE . If your very lucky you might get a lease back. If you have successfully written (a new object or object with no id.) you get null. If you update the lease contains the previous value. But hang on there is a flag! I hate flags. The NoWriteLease if set causes the method to return null in all situations. I wonder how you set that, the documentation has no link.

UpdateModifiers.WRITE_ONLY Could throw EntryAlreadyInSpaceException for objects that have an id and your writing a duplicate.

So as you can see, if I call this method changing the mode might mean I have to change the post execution traps, null handling etc. Very easy to introduce a bug inadvertently.

If anyone from GigaSpace or OpenSpace is reading, sorry but its been a long day and I had to walk 4 miles through the snow to get home! While you amending the API onto an otherwise excellent product, could you update your more general documentaiton. Its very use case based. This is great when my use case matches your documentation, but most of the time this is not the case. So it becomes a nightmare picking pieces from here and there hoping its all going to work. I drive everything from tests but it gets a bit tedious when my tests fail because my assumptions are wrong.

UpdateModifiers is also not an enum but a constants class. As such the evil modifier is not even type or boundary safe.

Anyway before this blog turns into a rant. It may already be too late, sorry.

For discussion – Suggestion for a new API

write(T entry
    , long lease, TimeUnit leaseUnit
    , long timeout, TimeUnit timeoutUnit)

writeOrUpdate(T entry
    , long lease, TimeUnit leaseUnit
    , long timeout, TimeUnit timeoutUnit)

update(T entry
    , long lease, TimeUnit leaseUnit
    , long timeout, TimeUnit timeoutUnit)

partialUpdate(T entry
    , long lease, TimeUnit leaseUnit
    , long timeout, TimeUnit timeoutUnit)

Untangling a Gigaspace Pojo

Martin Harris — Mon, 21 Dec 2009 05:00:02 +0000

I am going to build myself another example application. I find these very handy for exploring ideas. If you already have a project with hibernate, spring, gigaspaces and such setup, your much more likely to try a few ideas out, and then blog them. So for a while this blog might be more quiet than usual. I think I may use Roo to do it. Roo looks like a great platform for quickly building something up for an experiment. i.e You can throw together a new set of entities, and then build an example on top of them. Before I begin, one last thing from my current experiments.

Sometimes JPA entity classes get hijacked.

Say for instance you have a need to pass entity classes to another system, via JAXB. Its possible to use DTO objects for the transfer or you could just annotate the the entity classes. In the example below, I wanted to fetch something from a database via JPA and write it into gigaspaces. It soon gets messy your Entity classes start to become a hub in the middle of your application with things dipping into some of the classes and annotating them and throwing them here and there.

Lets look at a simple one from my example system. This one is only used by gigaspaces and hibernate, it could get much messier than this if I chose to add one or two more technologies. I am deliberately leaving the imports in the examples so you can see where it all came from.

import com.gigaspaces.annotation.pojo.SpaceClass;
import com.gigaspaces.annotation.pojo.SpaceId;
import com.gigaspaces.annotation.pojo.SpaceRouting;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.Table;
import javax.persistence.Transient;

@Entity
@Table(name = "HOUSE")
@SpaceClass
public class MessyHouse {

    private String id;
    private String name;
    private String address;
    private String pageId;

    public MessyHouse() {
    }  

    @SpaceRouting
    @Transient
    public String getPageId() {
    return pageId;
    }

    public void setPageId(String pageId) {
    this.pageId = pageId;
    }

    @Id
    @GeneratedValue
    @Column(name = "HOUSE_ID")
    @SpaceId(autoGenerate = false)
    public String getId() {
    return id;
    }

    public void setId(String id) {
    this.id = id;
    }

    public String getAddress() {
    return address;
    }

    public void setAddress(String address) {
    this.address = address;
    }

    public String getName() {
    return name;
    }

    public void setName(String name) {
    this.name = name;
    }
}

Some things I dislike about what I have done here

See the block I have marked below SpaceRouting. In this class I wanted to change the Gigaspace routing strategy, so I have a method that has nothing to do with the persistence. Does adding annotations break the “A class should have only one responsibility” design goal? No perhaps not, but adding a whole method that is a Gigaspace concern does.
As you add more and more annotations from different technologies things get messy very quickly.
I have a JPA based DAO that uses this class. I also have a set of gigaspace processing units that use this class. Both systems are impinging their own design requirements on the class. At the moment they are deceptively similar. Gigaspace insists upon a default constructor, and getters and setters for all fields you wish to persist. Hibernate is not quite as strict. What if Gigaspaces relaxes that rule later and allows you to annotate the fields instead? Or perhaps added some other design restriction. Its unclear by looking at the class what things are there for hibernates soft contract and what gigaspace is insisting upon.
If my gigaspace experiment gets big (not that likely!). I might want to split off the gigaspace into its own project and use it as a component. Ah! so what about the MessyHouse class then? Where should that live? Indeed its going to be in the wrong project wherever I decide to keep it.

This is one solution that I put to you. Create a class for the gigaspace fields, and compose a House class into it. With composition we can neatly separate the concerns. Well almost. Gigaspace may store these objects and need to restore them at some point. I believe to do that it creates House, and populates it. Then it creates GsHouseWrapper and injects House into it. To do that you need a setter for the house but at least we have a class with Gigaspace design constraints and another with Hibernate peculiarities. Check out the classes below and let me know what you make of the design. Are there alternatives?

Also, currently there is a problem with the design below. The delegation methods fail with an exception. i.e house.setId(id); fails when writing the object to the space. I need to submit a ticket with the Gigaspace crew to figure out why.

The refactored classes.

package javapuzzlers.compose;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
@Table(name = "HOUSE")
public class House {

    private String id;
    private String name;
    private String address;

    public House() {
    }

    @Id
    @GeneratedValue
    @Column(name = "HOUSE_ID")
    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

    public String getAddress() {
        return address;
    }

    public void setAddress(String address) {
        this.address = address;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

package javapuzzlers.compose;

import com.gigaspaces.annotation.pojo.SpaceClass;
import com.gigaspaces.annotation.pojo.SpaceId;
import com.gigaspaces.annotation.pojo.SpaceRouting;

@SpaceClass
public class GsHouseWrapper {

    private House house;
    private String pageId;

    public GsHouseWrapper() {
    }

    public GsHouseWrapper(House house) {
      this.house = house;
    }

    @SpaceId(autoGenerate = false)
    public String getId() {
        return house.getId();
    }

    public void setId(String id) {
        house.setId(id);
    }

    @SpaceRouting
    public String getPageId() {
        return pageId;
    }

    public void setPageId(String pageId) {
        this.pageId = pageId;
    }

    public GsHouseWrapper(House house) {
        this.house = house;
    }

    public String getName() {
        return house.getName();
    }

    public String getAddress() {
        return house.getAddress();
    }
}