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/

Like any other tool, XA has its use and can help if used properly or hurt a lot if misused. Not every problem in a distributed system is the same, and some require different solutions than others. XA is a performance hog and should not be used for frequent operations, but at least on the systems that I work with there are loads of operations that run once or twice a second where you aren’t going to notice a big difference. Reference data is often read-mostly and not updated that often. Caching it makes a lot of sense and that is where data grids come in.

If you are putting a cache on top of an existing system where the database is the most authoritative source of truth, changing all the apps is typically too costly. Database still has to remain the source of truth but updates to reference data should be coordinated with the cache – often by enqueuing a notification to change the cache or changing it directly. Unless you are using Oracle AQ or something similar which makes the queues use the same transaction manager as the database, there you have two resources in a transaction: the database and a queue or cache. And that is where full XA support really comes in. It guarantees that the database update and the queue/cache update will both succeed or fail so that there is no data corruption or inconsistency in the cache. Coherence has LLR XA support so there is a chance that the database update can go through and the grid commit fails because of temporary network issues. Without proper XA, you need to code around this, make simpler atomic operations that wrap one resource in other’s transaction and recover from errors manually etc. So a few cleverly designed XA operations can make the bulk of code where performance isn’t such an issue a lot simpler, easier to maintain, less error prone and easier to troubleshoot, leaving you with more time to deal with parts of the system where you really need to focus and where XA should not apply.

I just like the option of having it there if I need it and when I need it.

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, how they are picked up and processed, automatically hides the target objects frm other processors in parallel, has spring declarative transaction support and data mirroring etc, so it allows you to write parallel processing apps efficiently. Command pattern in Coherence is a good start, but not as fully-featured as Gigaspaces. That doesn’t mean that you cannot do parallel processing with Coherence – of course you can – but in my opinion it is easier to write it with Gigaspaces because the framework gives you more.