IBM & BEA to market Persistence EdgeXtend for distributed cache

Discussions

News: IBM & BEA to market Persistence EdgeXtend for distributed cache

  1. Next June, both IBM and BEA will be co-marketing Persistence's EdgeXtend module for their J2EE servers. Why does this matter? Because the EdgeXtend product itself is worth a close look. EdgeXtend will provide a distributed cache that will save companies from needing to replicate their database across deployments of an application.

    This is possible because the edgeXtend distributed cache will keep itself sychronized across all of its running instances in the world. Behind the layer of caches, edgeXtend can sychronize with a single or multiple databases. The end result? An application with replicated in-memory object caches, not replicated relational databases. Very cool stuff.

    Check out IBM and BEA to cut cost of distributed J2EE
  2. This may be a great news for BEA and IBM, but that shows
    Persistence is unable to market its container and is
    willing to sell its strongest feature.

    Is BEA gonna recommend Persistence over Javlin?

    CMP entity beans, entity relationships and Optimistic
    Concurrency were one of the cool features of Persistence.Is that also part of EdgeXtend.

    If not then Optimistic concurrency needs to be built, if you choose to deploy distributed cache.
  3. First of all, you might want to lookup this thread because there has already been some discussion on this subject. To answer some of the questions: EdgeXtend basically is the same as PowerTier - it includes the backend classes that wrap the native C++ implementation. (For PowerTier users: AFAIK, existing .per files that describe the persistent schema can be reused with EdgeXtend). It uses JCA to integrate the DB transactions into the container's. You basically get proprietary CMP implemented as transparently generated BMP.

    PowerTier's (and therefore EdgeXtend's) strength lies in its capabilities for O/R mapping. It does not use its own persistent store in the middle tier (as I believe Javlin does) but caches objects and relations that have already been read from the database. This cache is distributed, which means that you can set up a clustered environmment with multiple caches that will all be synchronized transparently. IMHO, you won't need the distributed caching feature in all but the biggest applications - to me, this is just the way Persistence chose to market their technology. What it gives you even in small applications is the ability to use an EJB2.0-like model (each entity becomes an entity bean) in EJB1.1 containers.

    (BTW, I'm not connected to Persistence in any way, we just use PowerTier in a customer's project and had a presentation of EdgeXtend a few weeks ago.)
  4. What is distributed cache? Can anyone help me get pointers to it?

    Thanks in advance.
  5. Basically a persistent cache is an object-database optimized for caching data from external systems (mostly RDBMS) closer to the entity-beans. The mapping back and forth from the object-model to the external systems for each transaction takes up too much time. The caching of the already-mapped objects in an object-database in the middle-tier boosts the performance.

    Of course, if you carefully design your system around well-known and proven industry-patterns you won't need it.

    Basically, it is a remarketing of the object-database but you probably won't see that anyware in the marketing-bullshit.
    The following vendors I know about:
    http://www.gemstone.com/ (Facets)
    http://www.persistence.com/ (EdgeXTend)
    http://www.odi.com/ (Javlin)
  6. EdgeXtend is not (and never was) an object database. Neither is PowerTier. The cache is not persistent, but distributed. It would be more appropriate to compare EdgeXtend to TopLink or CocoBase than to Javlin or Facets.
  7. IMHO a distributed cache is useful in almost all applications. It allows you to scale your application on a cluster, which saves you money in the following two ways:

    1. For your app server you can buy a few, modest machines, which together are cheaper than a single, big server.

    2. You drastically cut the number of reads on your database, which allows you to use a smaller database machine, which in turn saves you hundreds of thousands of dollars in the database license.

    I am very curious to see how it performs.

    Guglielmo


  8. 1. For your app server you can buy a few, modest machines, >which together are cheaper than a single, big server.


    This may be true, but you need to take into account that you need to manage multiple machines, which will increase your cost. I believe that this depends very much on your scenario.

    >2. You drastically cut the number of reads on your >database, which allows you to use a smaller database >machine, which in turn saves you hundreds of thousands of >dollars in the database license

    This is related to caching in general, not to distributed caching.
  9. 1. For your app server you can buy a few, modest machines, which together are cheaper than a single, big server.


    >This may be true, but you need to take into account that you need to manage multiple machines, which will increase your cost. I believe that this depends very much on your scenario.

    What are the various scenarios that you had in mind?

    >>2. You drastically cut the number of reads on your database, which allows you to use a smaller database machine, which in turn saves you hundreds of thousands of dollars in the database license.

    >This is related to caching in general, not to distributed caching.

    Yes, but if the cache is not distributed you cannot scale on a cluster, you need an SMP.

    Guglielmo

  10. I'd be a bit wary about claims of doing wide-area distributed cache synchronization. A private redundant LAN or cluster based synchro has such a small failure window during state transfer that it's quite useful, but with a WAN you're bitten by the latency bug, creating one hell of a time to ensure a globally consistent state (hmm, did that node crash or is it just slow?).

    It all depends on what you're trying to do. Not all systems are shopping catalogs.. Quite a few are update intensive, something that's better suited to a replicated database that can use application semantics to determine synchronization policy.
  11. <Quote>
    >I'd be a bit wary about claims of doing wide-area >distributed cache synchronization.
    >
    >with a WAN you're bitten by the latency bug, creating one >hell of a time to ensure a globally consistent state (hmm, >did that node crash or is it just slow?).
    </Quote>

    Yeah, in theory it sounds good, but synchronization is problematic under just about any conditions. There are just some things that are out of your control...