Shay

Gojko, I applaud your efforts to help people compare the products. In my experience, doing my own comparisons and helping customers do theirs, the differences between the products tend not to show up until you go much deeper. While the features you describe are common to all of the top products, each of the vendors implement their solutions using some significant differences in their underlying technology, and these differences tend to show up only in full-scale performance tests. These tests, unfortunately, are tricky to build and execute, and if you decide to undertake them, I highly recommend you engage each vendor to help you configure and tune each test.

All cluster products will tend to offer some level of dynamic capacity capability. However, without the right options and tuning parameters, small performance problems can cascade into total cluster collapse. This is one area that we have dedicated significant effort to, making sure the cluster behaves well in cases of adversity (node failure, congested networks, slow message consumers, etc). This is an extremely difficult problem to solve, and is one of the biggest reasons for choosing a commercial product over an open-source solution. It is also a difference that doesn’t show up with a paper comparison of the products.

I would echo the comments from some of the other folks that warn of the problems of transactions, distributed or otherwise. The products tend to support them, but that doesn’t make their use a good idea. Yes, it takes some effort to code around the edge conditions properly, but this effort is more than rewarded when it comes to the overall scalability of the system. I would direct you to an independent (well, now he works for Microsoft) paper on the topic by Pat Helland (http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf).

Good luck with your project.

David Brown – GemStone GemFire

> Gigaspaces is a JavaSpaces implementation, and as such it is ideal for building
> master/worker (task dispatching) solutions.

Ideal but not limited to. Gigaspaces gives you JINI + Project RIO + JAVASPACE.

I never considered the benefits of a Javaspaces without considering those of JINI, maybe that is what is missing in these discussions?

Ale

I think your explanation of LLR XA resources is incorrect. From what I know (which could be wrong LLR resources are prepared usually prepared last, but committed first and hence the problem you attribute to inconsistent state is incorrect. It has nothing to do with Coherence (per say) but is often a problem with underlying XA TMs. Having build a non-logging XA resource for Coherence that is part of a multi-billion dollar trading platform, I’m pretty confident that it’s ok.

– Brian

BTW: If the last resource in any XA transaction commit fails, you’re pretty much in an “unstable state”, especially if the resource can’t be recovered cleanly. LLR basically makes it explicit and lowers the XA implementation SLAs . Failure during perpare is always. Failure during commit typically means someone has to talk to a DBA.

> The reason why I suggested Gigaspaces over Coherence for
> processing is that it is built around a processing model and
> has a lot of flexibility in terms of how you dispatch tasks

Coherence is a fully clustered data grid, and as such it is ideal for building large-scale state machines.

Gigaspaces is a JavaSpaces implementation, and as such it is ideal for building master/worker (task dispatching) solutions.

I wish you luck with your selection, and suggest you keep an eye on the Coherence Incubator (http://coherence.oracle.com/display/INCUBATOR/) for more than just the command pattern

Peace,

Cameron Purdy | Oracle Coherence
http://coherence.oracle.com/