GigaSpaces Releases Version 3.2

Discussions

News: GigaSpaces Releases Version 3.2

  1. GigaSpaces Releases Version 3.2 (46 messages)

    GigaSpaces is pleased to announce the release of GigaSpaces Platform 3.2 for free evaluation. GigaSpaces Platform is a commercial implementation of JavaSpaces and a clustered space implementation with flexible clustering policies, including SSI. The caching implementation can be accessed using the rich JavaSpaces API and the standard Java Map interface.

    New Features

    - Distributed caching
    - One-Click-Cluster
    - Optimistic locking
    - Data eviction
    - Failover backup
    - Batch update
    - Atomic update
    - HTTP session sharing based on distributed caching
    - Automatic failure recovery
    - Automatic space creation
    - Multi-space URL
    - User-defined UID.
    - The popular Postgres SQL RDBMS is now supported
    - Jini 2.0 support
    - .Net interface introduced

    Read about the GigaSpaces 3.2 Release

    Download the free evaluation

    Threaded Messages (46)

  2. Great stuff![ Go to top ]

    Slightly old news since we've been using 3.2 for a while now but even after 2 whole weeks it's still way ahead of its time! :-)

    If you don't know what Jini is then you'd better catch up, this is the famous GRID technology that's changing the internet and computing as we know it. Well so the marketing tells us but however you look at it, it's a darn site more interesting than hyped technologies like WebServices.

    When you compare Jini to the more heavyweight J2EE solutions it's very attractive, you've got similar external connectivity, WebServices and other .NET integration solutions, J2EE integration, JNI etc. Jini supports transaction, is linearly scalable, unbelievably simple to use, they even got standard industry solutions.

    -John- (great fan of Jini)
  3. I wonder how it compares to - say Tangosol/Coherence - when it is used as ditributed read/write clustered cache behind a J2EE stack ?

    Laurent.
  4. Laurent,
        Hi, still at the same place? This is a good question, I hope we can get one of the Jini vendors to answer this question. Rather than see raw benchmarks I'd like to see the pros and cons.

    For me, I'm finding the J2EE stack rather heavyweight for a lot of situations, Servlets, JSPs and Struts do the majority of the jobs but JavaSpaces would be my solution of choice for High Performance Computing (HPC). It's just so much simpler than a traditional J2EE App Servers. I'm not saying J2EE is wrong, I'm a great fan of the whole stack, EJBs, JCA, JMS etc. I just like to use the right tool for the right job and Jini is more often the right tool than a full J2EE App Server for what I'm doing. I know what you are (or were) working on and that's a whole different store altogether.

    I would love to be able to try out some of the benchmarks you were working on a year or so ago with with Jini rather than on J2EE. I can remember those big 200 CPU benchmarks, that would be a great test of "real" work and a little more relevant that a pet store :-).

    Regards,

    -John-
  5. Hi all,

    I would be very interested in some actual projects feedback (performance, daily production management, project lifecycle (patches, etc))...

    Specs does not make it all, we like robust technologies, but we want our projects to be easy to maintain and easy to monitor...

    does anybody know where I could read about some real-life experiences?

    thx!
    --
    Joseph
  6. Hi Joseph,

    GigaSpaces is used in medium and large scale projects in the finance , telecom and defense verticals.

    Our latest project with Merrill Lynch has been published lately. You can find it here:
    http://www.gigaspaces.com/whitepaper.htm

    Regarding benchmarks. See our benchmark report here:
    http://www.gigaspaces.com/benchmarks.htm

    Our latest 3.2 tests show you can write/read/take more than 20,000 entries per second into embedded space using 1MB RAM 1 Intel based CPU 2.5 Mhz with many concurrent users. Using remote space you can write/read/take more than 2,000 entries per second. These results will be published soon.

    For more info please send your requests to sales at gigaspaces dot com

    Shay
  7. Shay,

    thanks for the info, but I have already read whitepapers..

    The Merrill Lynch project is said to be a pilot, not a real life one, i.e. with production issues, deployment new versions of the programs (with datamodel migration), etc.

    --
    Joseph
  8. Joseph
    See my answer below.

    > Shay,
    >
    > thanks for the info, but I have already read whitepapers..
    >
    > The Merrill Lynch project is said to be a pilot, not a real life one, i.e. with production issues, deployment new versions of the programs (with datamodel migration), etc.
    >
    > --
    > Joseph

    All of the cases that were mentioned earlier by shay were taken from real customers cases. ( AIG,H3G, BAT, And even the US Army). This is only a partial list. From obvious reasons I can't expose many of the other big names in this thread.

    Working closely customers is one of GigaSpaces main assets. Before we come up with a solution we learn well the problem, generalize it and then come up with a generic solution. Therefore you can assume that every piece in the product is derived from real business/customer needs.
    I think that John Davis from C24 is a good example for such experience.

    Unfortunately I cannot expose the technical details of this experience in this thread but I would be happy to answer any specific questions if you would approach me directly natis at gigaspaces dot com .


    Nati S.
    GigaSpaces CTO
  9. Joseph ol' chap, how are you!?
        We're using Jini for real life banking projects, in fact a bank very close to you are looking at using it for Murex/FpML matching and reconciliation.

    We're performing about 1500 times better then the requirements so far but I'll leave the actual benchmarks until we get real life data. It will of course be written up here if we get permission, I'll call you...

    -John-
  10. Yes, still at the same place...[ Go to top ]

    hi John,

    how strange what SUN invents never find its way for what it has been designed as the first place. (I believe this is the case with many great inventions)
    Remember Java, which was supposed to operate interactive TV decoder...
    and now jini that was - according to Bill Joy - supposed to solve the problem of network device connection and self discovery.

    A part from that, let me tell you some news about my project.
    We are now close to go live (well in Q4 this year !). Because the code is full object oriented we have finally made the decision to replace our service oriented database access layer with Hibernate. April benchmarks on actual code will tell !
    It might happen that one day or another we take a look at something like Coherence (stay calm Cameron;)) or gigaspace; but nothing decided yet on that side...we still believe Oracle + EMC can sustain the load.

    Thanks everybody to give such usefull pieces of infos on new tech toys.

    Laurent.
  11. Hi Laurent,

    The GigaSpaces 3.2 distributed caching facility has been designed to solve many of the current J2EE problems. You can use both JavaSpaces API or the simple map interface from regular Java application or from EJB component through GigaSpaces JCA:

    See:
    http://www.gigaspaces.com/docs/doc/index.htm#the_cache_api.htm
    http://www.gigaspaces.com/docs/JavaDoc/com/j_spaces/dcache/IDCacheMap.html
    http://www.gigaspaces.com/docs/JavaDoc/com/j_spaces/jca/GSInteraction.html#getDCacheMap()


    Regarding Usage scenarios. See below several usage scenarios for the GigaSpaces 3.2 distributed caching facility:
    - Reducing the I/O overhead when accessing distributed information:
    This scenario is one of the most common scenarios when using a cache facility.
    In this scenario, the application can improve the performance of accessing a remote data source, by transferring it closer to the application. The cache facility enables the mechanism to store, synchronize and manage the remote data-source information in a local memory. Thus, it saves the amount of time taken to access the remote data-source.
    - Reliable memory storage:
    One of the problems when storing information in memory is the lack of reliability and sharing capabilities of memory resources. For example, the need for maintaining the application state, while keeping it highly available. In the case of one servers failure, another one is able to recover from the point of deficiency, without losing the first servers state.
    The caching system adds reliability and sharing capabilities to the memory resources, and therefore the application can even maintain critical information in the memory. This can be done without compromising for either performance or reliability.
    - Distributed session sharing:
    Session information represents intermediate information. This information normally contains counters, users billing information, profiling information and in many cases HTTP session cookies. This information is critical to the application during the session or even during a specific operation, and it is completely useless afterwards. In these periods of time, session information needs to be accessed at a high speed.
    In distributed applications, the session information needs to be shared by multiple applications. A true caching system provides high performance data-storing, which is optimized for session information. It utilizes memory resources, and therefore provides high-performance access to session information.
    - Caching of user profiles and personalized information in a portal application:
    In a portal application, personalization usually requires the compilation of users profile preferences, with specific page content. Since HTML pages in a portal can be built from multiple portlets and pages, this process can be very expensive in terms of performance. In a single process, storing the profile information in-memory by a portal scenario may be sufficient. In a distributed portal environment, the user profile needs to be maintained consistently across all portal instances. In such an environment, the distributed cache facility enables access to users profile information at in-memory speed. This is done while maintaining consistency of information across multiple portal instances.
    - Grid:
    A Grid environment is a means of utilizing distributed CPU resources, to perform complex computational tasks. One of the bottlenecks in performing such tasks is access to the information associated with these tasks. In many cases, this information resides either in a centralized database or file system. As a result, the access for this information becomes a bottleneck and at some level becomes a real obstacle for performing a parallel task. Examples for such information are conversion tables, processing rules and user profiles. The caching system Data Grid solves this bottleneck, by allowing each processing unit to load this information into its memory address-space on demand.

    Shay
  12. Laurent: I wonder how it compares to - say Tangosol/Coherence - when it is used as ditributed read/write clustered cache behind a J2EE stack ?

    This is a Gigaspaces thread, so I'd rather not hijack it. (And congratulations to them on the release!) There's undoubtably overlap between what they're doing and what we're doing, because we're both concentrating on distributed computing, clustering, data management, and various grid buzzwords. So, having different choices and appproaches in the market can't be a bad thing ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  13. Can this distributed technology be applied on a network where some of the participating servers are connected to the network through low speed connections (like an office-shared 64k connection)? This is a specific need I have in a project I am currently working with, we are evaluating ditributing a CPU-intensive, data-intensive information system to remote locations, in order to improve system performance (users would connect to the local server and not to a central one as it is done today). Is it feasible with this technology, or does it depend upon a high speed (ethernet) network in order to work correctly?

    TIA,
    Henrique Steckelberg
  14. Hi TIA


    "> Can this distributed technology be applied on a network where some of the participating servers are connected to the network through low speed connections (like an office-shared 64k connection)? This is a specific need I have in a project I am currently working with, we are evaluating ditributing a CPU-intensive, data-intensive information system to remote locations, in order to improve system performance (users would connect to the local server and not to a central one as it is done today). Is it feasible with this technology, or does it depend upon a high speed (ethernet) network in order to work correctly?
    >"
     
    The answer is definitely yes.

    We have several optimization designed specifically for this cases.
    Actually we are currently involved in project that involves multiple geographical locations that need to be in sync in real-time over 128kb and 64kb lines. One of thier concerns was latency and we had been able to prove that we can exceed the performance of most alternatives due to "transparent" RPC batching algorithms and smart caching, that basically reduces the network overhead and thus increased the bandwidth utilization.

    Can you be more specific about your needs in terms of the size of the objects, the latency requirements and amount of updates per second.

    Nati S.
    CTO GigaSpaces
  15. Sorry i ment
    Hi Henrique
  16. Great stuff![ Go to top ]

    test
  17. GigaSpaces Releases Version 3.2[ Go to top ]

    Let me clarify something here...
    Both Tangosol and GigaSpaces have distributed cache features (as far as I know for Tangosol this is the only feature). Granted that for many computational grid tasks (and we are talking about computational grids here) the distributed caching functionality is essential but by no means is required. There many computation tasks that won’t require distributed caching or such functionality needs to be much customized. Furthermore, in order to run computational grid tasks one would need a lot more then just distributed caching and some rudimentary cluster capabilities… Any your favorite resource about grid computing will fill you up with resource management, task splitting, result aggregation, topology management, etc. – all of them in one form or another required for any serious infrastructure for computational grids.

    Also, the fact that something is based on Jini technology has little to do with grid computing per se (although the fact itself is very interesting). It is like saying that if we have TCP/IP connection service we are Internet browser...

    Best regards,
    Nikita Ivanov.
    xTier - Serice Oriented Middleware
  18. GigaSpaces Releases Version 3.2[ Go to top ]

    Nikita: Both Tangosol and GigaSpaces have distributed cache features (as far as I know for Tangosol this is the only feature). Granted that for many computational grid tasks (and we are talking about computational grids here) the distributed caching functionality is essential but by no means is required. There many computation tasks that won’t require distributed caching or such functionality needs to be much customized. Furthermore, in order to run computational grid tasks one would need a lot more then just distributed caching and some rudimentary cluster capabilities…

    Nikita, you have fallen into the typical technologist trap. You have set out to build a compelling and complete and perfect solution to all possible technical problems, and people aren't beating down your doors to buy it. And having found yourself in such a place, you start to look for others to blame for your predicament. There's no reason to start lobbing verbal grenades at products that you view as competition (e.g. talking about other products' "rudimentary cluster capabilities.") Just ask your customers (or potential customers) what it is that they need, then go and do it for them, and they'll give you money. It really is that simple.

    You'll note that John Davies is posting repeatedly about the benefits that he gets from JavaSpaces. I'd suggest you ask him for some time, and listen to what he has to say. Getting someone like John to use and evangelize the use of your products will go a long way. (I'm jealous as hell that he's not talking about mine ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  19. GigaSpaces Releases Version 3.2[ Go to top ]

    Hi Cameron,
    Well, I was expecting you take it so personally :-)
    In fact, spinning “grid computing” message for marketing scores only is ok in my book – so no need to be defensive/offensive. Tangosol (now in particular) has nothing to do with grid computing as well as GigaSpaces – that’s all I wanted to point. Tangosol has great Java-based distributed caching product – and that’s all, and GigaSpaces has something similar to that (to the best of my understanding of their publicly available information) plus some other pieces. Just mere fact that both products have some clustering capabilities, for example, doesn’t make them grid technologies too. I hope you’d agree with that.

    Now, as far as our product (since you alluded to it) we are releasing a dedicated computational grid service (along with distributed caching, clustering, configuration and 15 other services) that specifically addresses how to take a task and run in on the grid. And that, as you can imagine, involves a lot more then just caching or clustering.

    As far as Jine/JavaSpaces, for me it’s an old story (we have evaluated it 2-3 years ago), but may be because we are working in a cross-paradigm space. I am (positively) surprised that someone is making it into commercially viable product. I can only wish the best.

    Regards,
    Nikita.
    xTier - Service Oriented Middleware
  20. GigaSpaces Releases Version 3.2[ Go to top ]

    As far as Jine/JavaSpaces, for me it’s an old story (we have evaluated it 2-3 years ago), but may be because we are working in a cross-paradigm space. I am (positively) surprised that someone is making it into commercially viable product. I can only wish the best.


    How nieve (IMOHO), I suppose you evaluated Java in the 90s too, that's even older.

    Just because something is old or wasn't right then doesn't mean it's the same now. JavaSpaces come into their own with lots of memory, just like a cache. If you have little memory then there's little advantage to a cache, 2-3 years ago it wasn't "normal" to have 5-20 GB of RAM available in a middle of the road cluster. JavaSpaces was an academic novelty when it came out (just like Java, the internet and wireless networking etc.). It's a different story now, we have low cost Blade racks with tens of GBytes of RAM at affordable prices, perfect for JavaSpaces.

    According to your web site "The fundamental characteristic of xNova architecture is its broad independence from underlying technologies", so does it work with Jini then? If not you're missing out and you need to change your marketing. I suggest you get your CTO to try another evaluation, after all I'm sure you'd like the other readers of this to try your product again before 2-3 years are up?

    As Cameron says "Peace",

    -John-
  21. GigaSpaces Releases Version 3.2[ Go to top ]

    Hi John,
    As I stated we evaluated Jini/JavaSpaces as a plumbing and found it rather irrelevant both technically and marketing-wise. But it’s for our product and if you found it otherwise for other applications – good for you.

    As far as our product, we work with any J2SE or CLR-based codebase through our microkernel layer. So, whether it's Jini, WebLogic, Windows Server 2003, GigaSpaces or even Coherence, it is the same for us – matter of specific microkernel.

    But coming back to the original point I will state it again that Jini/JavaSpaces simply doesn't mean grid technology (look up my previous posts for details) - and that's all, although it possibly can be used as a low level plumbing to start implementing one. I understand everyone's desire to jump on the train with little substance but this place is already polluted enough to allow it further.

    Best regards,
    Niktia.
    xTier - Service Oriented Middleware
  22. GigaSpaces Releases Version 3.2[ Go to top ]

    we evaluated Jini/JavaSpaces as a plumbing and found it rather irrelevant both technically and marketing-wise


    I'm glad there are companies that do find it irrelevant, it leaves more space for us and doesn't confuse our customers with too much choice.

    We're not using it for plumbing, we're using it for high availability, distributed rules/workflow (ECA) and distributes high performance computing.

    -John-
  23. GigaSpaces Releases Version 3.2[ Go to top ]

    We're not using it [Jini] for plumbing, we're using it for high availability, distributed rules/workflow (ECA) and distributes high performance computing.

    If Jini were ideal, Sun never would've moved on to JXTA. All of the missions you mention above are covered by existing or emerging (eg, WS-Resource, WS-Discovery) web service specifications. Grid, p2p, and web service are merging into these new web service specifications.
  24. GigaSpaces Releases Version 3.2[ Go to top ]

    If Jini were ideal, Sun never would've moved on to JXTA


    Classic mistake, the are as similar as RMI and SOAP and accordingly designed for different usages.

    You'd be off your rocker to design a HPC system using JXTA similarly you'd hardly expect Jini's RMI to work well over a WAN.

    It all comes down to architecture, just because two different technologies look the same from the ourside doesn't mean they compete.

    -John-
  25. GigaSpaces Releases Version 3.2[ Go to top ]

    You'd be off your rocker to design a HPC system using JXTA...

    Ray Gao, one of Sun's Vice Presidents, has a project to build a compute grid with JXTA fabric. No shit: http://jxta-grid.jxta.org


    ...similarly you'd hardly expect Jini's RMI to work well over a WAN.

    A grid isn't about your LAN. It's about aggregating more resources than you own. It's about using other people's stuff to collaborate at e-science, etc. A WAN is crucial for sharing.
  26. Grid definitions[ Go to top ]

    A grid isn't about your LAN. It's about aggregating more resources than you own. It's about using other people's stuff to collaborate at e-science, etc. A WAN is crucial for sharing.

    That's only one of several definitions of grid computing. Most (most) grid projects are within the datacenter, not across "other people's PCs."

    Both of these types are pretty interesting, but they are as different as night and day. Most grid rollouts are being done in big corporations, because that's where the money is. Most are financial services. Most are datacenter based.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  27. Grid definitions[ Go to top ]

    That's only one of several definitions of grid computing. Most (most) grid projects are within the datacenter, not across "other people's PCs."


    Gartner makes the distinction by calling these server-side grids. I'm not sure how widely these type of grids are being used, I've only come across their use for risk calculations - I'd be interested to know where else they might be used in the data center?

    cheers,

    Rob
  28. Grid definitions[ Go to top ]

    We've seen them in all the "big names" in the financial services industry. (We're typically the component that provides the "data grid" functionality.) A year ago, 90% of these were just "pilots" but this year probably 50% or better are LOB. Both types of projects get used, but LOB means that the grid apps are providing services to other apps and have to actually meet their SLAs and can't change their service APIs every two days (or without long committee meetings ;-).

    There's a lot going on in biotech (some data center, some not) and GIS (data center grids) too, but they're a full cycle behind the financial services companies (from what I've personally seen.) On the government side, they're into grid computing big-time, and those are all data center grids, but if I told you about the projects that I've seen, I'd have to kill you ;-).

    As far as sizes go, the larger ones are in the thousands of CPUs, and the smaller ones are in the tens of CPUs. Sometimes the grids are of a fixed size and configuration, and some companies go at it more dynamically (deploying apps in pseudo real time based on the resource needs at that time.) Everyone defines what a "grid" is slightly differently, and for the time being it's largely a concept, moreso than being a definition. The two main parts of the concept are "utility computing," meaning "power on demand," and a redundancy and resiliency of interconnects such that a partial failure of the (or "in the") grid doesn't take down the whole service.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  29. Grid definitions[ Go to top ]

    Everyone defines what a "grid" is slightly differently...

    The trick is to arrive at a definition that has meaning beyond what a "mere cluster" has historicly denoted.
  30. Grid definitions[ Go to top ]

    <Cameron>
    Everyone defines what a "grid" is slightly differently, and for the time being it's largely a concept, moreso than being a definition. The two main parts of the concept are "utility computing," meaning "power on demand," and a redundancy and resiliency of interconnects such that a partial failure of the (or "in the") grid doesn't take down the whole service.
    </Cameron>

    I agree that grid definition is not put in stone. I tend however to simplify the grid “story” to give it an elevator pitch instead of producing long buzz-word filled sentences that are more appropriate for academia. In a nutshell, grid has two major types: computational and data grids. Each of these grids can be "enterprise" and "global". All of these (4) terms are extremely well defined and well used in grid community.

    Each type of grid has very unique set of requirements and implementation strategies. To reiterate my point that I made earlier on this thread, the "enterprise computational grids" have the biggest chance for wide-spread business adoption. This fact, actually, is almost axiomatic nowadays.

    As far as "two main parts" and "utility computing" in particular it has very little to do with grid computing per-se and I think it is a usual misconception again. The fact that both utility computing and grid computing using large farms of CPUs doesn’t make them the same technology... (I thought this topic was completely chewed up 1-2 years ago when IBM made this splash). Redundancy and resilience can potentially be associated with data grid functionality but rather solved today with different means such as DB clustering, NAS/SAN, software replicable caching, etc. In fact, most of today’s data grid products deal with high availability (i.e. search-ability, etc).

    Regards,
    Nikita.
    xTier - Service Oriented Middleware
  31. Grid definitions[ Go to top ]

    In a nutshell, grid has two major types: computational and data grids. Each of these grids can be "enterprise" and "global". All of these (4) terms are extremely well defined and well used in grid community.

    First in my mind are single sign on and virtual organization. The implications are heterogeneity, latency, and failure. I also dig Cameron's definition.


    ...software replicable caching...

    Google: 0 hits. What does Nikita mean?
  32. Grid definitions[ Go to top ]

    Hi Brian,
    Any permutations of words "software", "replicable" and "cache" should fetch hundreds if not thousands links on Google...

    Coherence, for example, is an example of cache with replicable foundation. In simplified terms – it replicates data on update to other node(s). We (xTier) don’t believe much in replicable cache and so we have patented non-replicable cache where we don’t replicate anything on update - but rather invalidate necessary records on other node(s).

    Each type of caching has its advantages and disadvantages. It could be very interesting discussion to have about various applicability scenarios for each of these distributed caching types.

    Hope it helps,
    Nikita.
    xTier - Service Oriented Middleware
  33. Grid definitions[ Go to top ]

    It could be very interesting discussion to have about various applicability scenarios for each of these distributed caching types.

    Ok. Say some designers are remotely collaborating on a shared X3D document. Ie, collaborative teleimmersion with content encoded as 3D XML. How does distributed caching keep their virtual realities synchronized in the face of DOM mutation events? I just don't see how.
  34. Grid definitions[ Go to top ]

    Hi Brian,

    GigaSpaces distributed caching provides both push and pull (invalidate) synchronization methods.
    You can have both P2P caching between different applications or have master cache which holds all the data. The client side got its local data that is evicted based on LRU bases. The master cache could be clustered and/or persistent into any RDBMS using classic OR mapping. As you can see we deigned the system from bottom up to be maximum flexible with the ability to be customized very easily.

    Regarding the X3D document example you had: Lets say you have multiple distributed clients using huge amount of X3D documents. You can have the X3D document to be stored as multiple entries in the space. Every client will have its own view of this X3D document components. All objects that need to be read again and again will be available immediately at the client side. Other X3D document components that need to be updated will be pushed directly into each relevant client local cache .
    With such architecture you can have your data distributed among many clients , where each one got its part of the data (since each client might have different read criterias) , and a master cache which hold all the data.
    This will provide maximum performance , scalability and availability. In other words you will have powerful Data-Grid that will make sure your distributed clients will have SSI with coherent and consistent data.

    Sounds reasonable?

    Regards,
    Shay
    ---------------------------
    GigaSpaces product Manager
    www.gigaspaces.com
    shay@gigaspaces.com
  35. Grid definitions[ Go to top ]

    Nikita: Coherence, for example, is an example of cache with replicable foundation. In simplified terms – it replicates data on update to other node(s).

    Yes, Coherence supports fully replicated caches, @since 1.0.

    Optimistic replicated @since 1.1.

    Distributed (partitioned) @since 1.2.

    Near @since 2.0.

    Disk-based, overflow, direct buffer, memory-mapped file, etc. @since various.

    Computational grid @since 2.1.

    (I thought you knew that, since someone at your company has been downloading it pretty regularly. ;-)

    Nikita: We (xTier) don’t believe much in replicable cache ..

    What do I have to do to make you believe in them? Honestly, they exist ;-)

    Nikita: .. and so we have patented non-replicable cache where we don’t replicate anything on update - but rather invalidate necessary records on other node(s).

    Hmm. You patented that? Could you post a link to the patent?

    Coherence has supported version- and event-based Seppuku for several years now.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  36. GigaSpaces Releases Version 3.2[ Go to top ]

    You'll note that John Davies is posting repeatedly about the benefits that he gets from JavaSpaces. I'd suggest you ask him for some time, and listen to what he has to say. Getting someone like John to use and evangelize the use of your products will go a long way. (I'm jealous as hell that he's not talking about mine ;-)


    Cameron, Your time will come, I'm well aware of Coherence, it's well respected in J2EE circles as I'm sure you know. There are many many situations where I've recommended my clients look at Coherence.

    As for Jini/JavaSpaces, we just had a green-field development and chose Jini, for what we needed, it was the best fit and it works very well, it was a good choice.

    C24 are however still very much into J2EE, we have the WebLogic support contracts of two large UK companies, one a major high-steet retailer. We have conducted 7$ figure development projects in J2EE and it still features in the majority of our services work.

    We're a software house but still growing, I have three young boys and a wife to feed so we frequently prostitute ourselves in the form of support and services to keep the company going and pay the developers. J2EE features in about 95% of those contracts and I hope very soon I can find some business for Tangosol, Inc.. Until then I'll keep a good eye on it.

    Peace!

    -John-
  37. GigaSpaces Releases Version 3.2[ Go to top ]

    And having found yourself in such a place, you start to look for others to blame for your predicament.

    Ummm, maybe it's just me, but who's blaming others? And for that matter, what predicament? What place? Read the original post, there was no blame but instead a valid point about a grid computing infrastructure requiring more than just a Java cache product.

    There's no reason to start lobbing verbal grenades at products that you view as competition (e.g. talking about other products' rudimentary cluster capabilities.")

    If the shoe fits... And clearly your post couldn't be considered a verbal grenade; after all you signed it "peace".

    Just ask your customers (or potential customers) what it is that they need, then go and do it for them, and they'll give you money. It really is that simple.

    Gee Cameron, thanks for the "business lesson". (Note to self, talk to customers...) Perhaps rather than "build[ing] a compelling and complete and perfect solution to all possible technical problems" what we've done is build a compelling solution for a very specific set of technical problems. That is providing a comprehensive set of services for high-performance grid computing. I will agree with you on one point, having different choices and appproaches(sic) in the market can't be a bad thing and that's exactly what we were talking about here.

    Your post has impressively missed the point and launched a condescending tangential attack all the while masquerading as a proclamation of wounded innocence. Please, spare me.

    Distributed caching is usefully when building computational grids, and hey, Tangasol does a great job, but Java caching is not the only part of the solution. The relative immaturity of the grid computing marketplace allows a lot of misinformation to get out there and positing that the only requirement for a grid computing infrastructure is Java caching is misleading at best.

    You have managed to do exactly what you are supposedly posting against, that is to launch a "verbal grenade" when an opinion differs from your own or your product strategy. Perhaps the TSS community would be better served by a discussion of the technical points that were raised in the post.

    As for the GigaSpaces release, which this post should be about, congratulations! Anytime a new release goes out the door the hard work of all involved should be noted.

    Best Regards,
    Jon Webster
    xTier - Service Oriented Middleware
  38. GigaSpaces & Grid[ Go to top ]

    GigaSpaces is primary focused on Real-Time Data-Grid and not computational Grid.
    It is real-time since it is based on the utilization of memory resources (and not disks).
    It has been used and is still used in many grid projects both in the universities and in the industry.

    See below the references for some of the academic projects.
    academic projects
     
    Since our technology is based on the JavaSpaces model it can be used very easily for performing simple parallel processing tasks. For complex computational tasks our approach is to integrate with other Grid Platforms.

    Nati S.
  39. GigaSpaces & Grid[ Go to top ]

    Hi Nati,
    Thanks for clarification. Data grids and computational grid are miles apart as far requirements and implementation strategies. In our initial research we found however that data grids have significantly less business acceptance because many massive data storage/availability problems can be solved by existing NAS/SAN solutions or by software caching, while computational grids don’t have direct and present solution.

    (...by the way, I was painstakingly referring to computational grids in all my post but I guess these terms are still in novelty for some...)

    In our grid service we are also emphasizing near real-time capabilities and it is interesting you have mentioned that. I believe that real business adoption of grid technology will come from applying grid for relatively short-term tasks (seconds and may be minutes but not hours) and by making grid technology itself more commoditized in terms of pricing and development. In the end of the day, only DOD/DOE, biotech, some financial application and such would have massive computational task that would require months of processing making it a rather special market. If, as I mentioned, grid technology would become readily available, easy to develop with and designed with real business tasks in mind – that’s where we can see a much faster growth in grid adoption.


    Best regards,
    Nikita Ivanov.
    xTier - Service Oritented Middleware
  40. GigaSpaces & Grid[ Go to top ]

    Nikita: ... while computational grids don’t have direct and present solution.

    Globus? http://www.globus.org/
    Platform? http://www.platform.com/
    Data Synapse? http://www.datasynapse.com/

    These are just a few of the names that we see out there. And from what I've seen, getting the data into the grid is much harder for these projects than getting code to run on thousands of CPUs.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  41. GigaSpaces & Grid[ Go to top ]

    Nikita: ... while computational grids don’t have direct and present solution.

    >
    > Globus? http://www.globus.org/
    > Platform? http://www.platform.com/
    > Data Synapse? http://www.datasynapse.com/
    >
    > These are just a few of the names that we see out there. And from what I've seen, getting the data into the grid is much harder for these projects than getting code to run on thousands of CPUs.
    >

    Cameron,
    You are missing the point again. The names you mentioned (and some others) are the (computational) grid products that were developed to address the problem that computationally intensive tasks could not be resolved efficiently with then existing technologies.

    Many data intensive tasks (mostly, high availability oriented) on the other hand do have non-grid technologies that can solve them today. NAS/SAN and software (replicable) cache are just two perfect examples of non-grid technologies used today to solve such problems. On the other side, you can look at, for example, Avaki (www.avaki.com) that has dedicated data grid product and see that is quite different from just caching or just Jini, for that matter.

    Granted, the terminology landscape in grid computing is still fluid and we can argue all we want about each and every definition, but there are things that are well defined even at this "early" stage.

    My initial post was about the fact that you can’t just snap on "grid" moniker to any distributed technology and misled the readers about it (it is a technical forum after all) - and that applies to Jini conversation and it applies to cache argumentation. Those are fine technologies and products – they just have nothing to do with grid in particular although they can be used together, if needed. That’s all.

    Hope it helps,
    Nikita.
    xTier - Service Oritented Middleware
  42. GigaSpaces & Grid[ Go to top ]

    You're all missing the point -

    No Jini and Javaspaces doesn't magically qualify as a grid,
    but it does provide facilities (in conjunction with your own code) to build a dynamic grid built on top of the dynamic networking of Jini.

    Where you go from there into grid computing (computational or data grid) is up to you.

    I'm building a grid system, called Neon, using Jini and Javaspaces, custom-built asynchronous messaging between components (mobile agents) , yet providing a normal synchronous programming model for developers, allowing the entire structure of the grid and message channels to change even during calls between components, and transparent transactions across grid entities.

    I'll be doing a presentation about it (and using Jini/JS for EAI) at the 7th Jini Community Meeting at the end of the month

    http://www.jini.org/meetings/seventh/index.html

    Cheers
  43. GigaSpaces & Grid[ Go to top ]

    And from what I've seen, getting the data into the grid is much harder for these projects than getting code to run on thousands of CPUs.

    Indeed the strategy of our team is often (thanks to Java and Globus) to automaticly send the code to the data. It's a complete reversal of traditional network programming, but it's quicker to temporarily deploy an application than to fetch gigs of data.
  44. GigaSpaces & Grid[ Go to top ]

    In our initial research we found however that data grids have significantly less business acceptance because many massive data storage/availability problems can be solved by existing NAS/SAN solutions...

    The distinction between SAN and data grid is still unclear to me.

    If, as I mentioned, grid technology would become readily available, easy to develop with...

    What do you find difficult about grid application development? In my experience grid development is no harder than other forms of distributed programming. To me it's all n-tier stuff. Very straightforward.
  45. GigaSpaces & .NET[ Go to top ]

    Hi Nati,

    Real-Time Data-Grid (as opposed to computational Grid) sound very interesting indeed. It looks that you are raising the bar for high-performance Enterprise business! As you say, the popular CMS's (Content Manager Servers) quickly clogs down.

    I have a couple of questions,

    1) What is the preferred web application server to use with GigaSpaces. (Tomcat I hope!)
    2) Do I still need a J2EE server for distributed transactions and 2PC?
    3) Is the .NET API in C# and is it exactly up to par with the Java API?
    4) Can I use it on only one box or is it cluster only?
    5) What is the price! (for one computer)

    Regards
    Rolf Tollerud
  46. GigaSpaces & .NET[ Go to top ]

    Mr. Tollerud ,

    See my answers below:

    1) What is the preferred web application server to use with GigaSpaces. (Tomcat I hope!)

    - GigaSpaces embeds Tomcat. GigaSpaces is using it for web services support and code base download.

    2) Do I still need a J2EE server for distributed transactions and 2PC?

    - No. Jini is taking care of this. The Jini framework provides distributed transaction service that is 2PC. This is embedded with GigaSpaces server.

    3) Is the .NET API in C# and is it exactly up to par with the Java API?

    - The C# is exactly the same as the Java API.

    4) Can I use it on only one box or is it cluster only?

    - You can use single space configuration or clustered. That is your choice.

    5) What is the price! (for one computer)

    - Please send info to sales at gigaspaces dot com with your project requirements , number of installations and one of our sales reps will contact you for exact price.

    Best Regards,
            Shay
    ----------------------------------------
    Shay Hassidim
    Product Manager, GigaSpaces Technologies
    Email: shay at gigaspaces dot com
    Website: www.gigaspaces.com
    GigaSpaces - Be Local Sync Global
  47. Hi,

    I would like to list the GigaSpaces Distributed Caching highlights.
    These will explain why GigaSpaces Distributed Caching is very unique with its approach:
    - Build on top of JavaSpaces and GigaSpaces embedded space technology
    - Provide JavaSpaces API and MAP API. This allow none JavaSpaces users to use the most simple API - Map interface for distributed data caching.
    - Designed for high concurrent environments
    - Build on top of GRID based engine for maximum scalability
    - Central configuration with the ability to override it per client cache
    - The central configuration comes with build-in default definitions
    - The distributed cache can be P2P or Master cache configuration provides none-single-point-of-failure.
    - The Master cache can be clustered to provide high-availability and load-balancing
    - Smart client cache eviction algorithm
    - Using advanced optimistic locking protocol implementation.
    - Data to be cached does not have any restrictions - Every data type can be cached and does not need to implement or extends any interface/class
    - Designed along with market input and customers requirements
    - C++ , .Net , JCA interface
    - PUSH/PULL synchronization policies
    - Security support
    - GUI administration with XML file configuration
    - External data source integration

    Regards,
    Shay
    GigaSpaces Product Manager