• Scaling Tomcat with GigaSpaces

    Webserver session objects have existed since the beginning of web programming. Many developers see them as the most convenient way to store session information. While some of this information is temporary and should be deleted once the session expires, the rest should be saved in some sort of persistent storage for the user’s next visit. In recent years, web development has become more and more challenging, session data size has increased greatly to support the data the user expects to
    Read More

  • When Big-IT meets Big-Web

    Last week I had the honor to join an interesting event held by Battery Venture in Stanford titled “BiG IT meets Big Web” which brought together people from the financial industry (JP Morgan, NYSE, BOFA, Barclays, for example) and the…

  • Data Grid Querying, Revisited

    There has been a great deal of talk lately about the new EHCache cache querying capabilities and the advantages of real-time analytics through in-memory cache querying. I find that rather odd since extensive querying and processing capabilities have b…

  • GigaSpaces New Cloud Platform – Sneak Preview

    The presentation below provides a sneak preview into one of the cool features of our upcomming Cloud Enabled Application Platform – Uniersal Service Manager (USM). The universal service manager enable to handle the deployment, elasticity, continues avliability, scalabiltiy of existing…

  • GigaSpaces New Cloud Platform – Sneak Preview

    The presentation below provides a sneak preview into one of the cool features of our upcomming Cloud Enabled Application Platform – Uniersal Service Manager (USM). The universal service manager enable to handle the deployment, elasticity, continues avliability, scalabiltiy of existing…

  • GigaSpaces New Cloud Platform – Sneak Preview

    The presentation below provides a sneak preview into one of the cool features of our upcomming Cloud Enabled Application Platform – Uniersal Service Manager (USM). The universal service manager enable to handle the deployment, elasticity, continues avliability, scalabiltiy of existing…

  • Data Grid Querying, Revisited

    There has been a great deal of talk lately about the new EHCache cache querying capabilities and the advantages of real-time analytics through in-memory cache querying. I find that rather odd since extensive querying and processing capabilities have been around for years with in memory data grids like GigaSpaces XAP, Oracle Coherence, Gemstone GemFire and more recently Hazelcast and GridGain. So I don’t really understand the big fuss around EHCache finally supporting it….

    But that’s actually a great opportunity to revisit some of the work we’ve done in our recent 8.0 release in the context of querying. There are two main features we’ve introduced in 8.0 that take data grid querying to the next level.

    Complex Object Querying

    The first one is complex object graph querying. Simply put, you can now index and any type of property, at any nesting level, of your data grid objects: primitive types, user defined types, or collections/arrays of either.
    Think of an Author object, which has a collection of books, each of them containing a collection of user reviews.
    Here are just two examples of what you can achieve with XAP 8.0:
    • List all the Authors that wrote at list one sci-fi book:


    Author[] authors = gigaSpace.readMultiple(new SQLQuery<author>(Author.class,
    "books[*].genre = ‘Sci-Fi’ ORDER BY name",Integer.MAX_VALUE);

    • List all the Authors who have at least one book on which your friend on Facebook commented:


    Author[] authors = gigaSpace.readMultiple(new SQLQuery<author>(Author.class,
    "books[*].comments[*].username= ?", “myFacebookFriend”, Integer.MAX_VALUE);

    This goes hand in hand with our new Document support, so you can apply the above to schema free documents as well as just plain Java or .Net objects.

    GigaSpaces JPA

    The second feature is our all new JPA support. We believe this to be a major step towards ease of use and standardization of distributed data store access.

    There have been a lot of discussions in the developer community about how the “classic” querying and interaction models (such as SQL/JDBC and JPA) can be mapped to the world of distributed data stores (which in memory data grids are a part of).

    When it comes down to querying, each distributed data store defines its own querying language and semantics. Some are completely proprietary (e.g. EHCache’s new query DSL, or MongoDB’s query syntax), some are modeled after standard SQL to some extent or the other (e.g. GigaSpaces’ native querying support, Coherence’s recent QL, or GridGain’s query language).
    All of these seem be solid query implementations (naturally you can guess which one I like best :) ).

    But when developing to each of those products, you need to learn their interaction model, data access semantics (such as transaction management) and of course querying language.

    The first take at bridging the two worlds, and IMO pretty successful one considering the inherent difficulties in bridging the two models (see this presentation I’m giving at QCon London in two days), was actually done by Google almighty with the JPA support in AppEngine.
    Although not 100% standard (actually not even close), it gives you as a developer a very easy and familiar way to implement scalable data access on top of their BigTable data store, and a very clear migration path for putting your apps on AppEngine, should you choose to do so. It also makes your code a lot more portable since JPA, even a partial version of it, is still way more standard and portable than any proprietary API.

    GigaSpaces JPA – Design Principles

    When we initially thought of implementing a JPA interface to our data grid, we had the following goals in mind:

    • Make our user’s life easier by providing a standard way for the to interact with the data grid that will allow them to easily get up to speed with new applications, and port existing JEE applications more smoothly and quickly.
      For that, we created a thin layer on top of the excellent OpenJPA framework so that configuring a GigaSpaces EntityManagerFactory is a breeze if you’re already into JPA in general and OpenJPA in particular. We also managed to support a nice set of features from the JPA specification (actually more extensive than Google’s AppEngine JPA) so that most of the stuff users actually do with JPA is covered. Naturally, this is just our first take at this huge project, and we’ll add more and more capabilities as we move forward.
    • Enable our users to leverage the power and scalability of the data grid to scale their data access, even when they’re using JPA (which was originally designed for a centralized data model). This means exposing content based routing and data grid indexing to their JPA domain model, and abstracting away cluster wide transactions and queries.
    • Protect our users from making wrong implementation decisions when modeling and accessing their distributed data. In Google AppEngine’s terminology, this means supporting Owned Relationship only such that object graphs are not scattered across many nodes and are always limited to a single node.
    • Allow our users to use our powerful native APIs for functions that are not covered by the JPA specification, e.g. event handling, distributed task execution, and more. So it actually means that you can use the JPA API, while still operate on the same data model and entities via our native POJO based API. This is a very powerful concept that covers not only JPA but all of our data access APIs, we call Same Data, Any API and it means that you can operate on the same data using a variety of APIs – besides our native POJO API and JPA. For example, you can read a JPA entity as a document (in case you want to treat it in a more loosely flexible manner, or use our C++ client side API from native clients to read this data.

    See for Yourself

    We have just published an comprehensive tutorial that explains the principles of the our JPA implementation using the good old Spring PetClinic sample app (we’ve added our own flavor to it :) ). It explains the data model considerations and shows how take advantage of data grid features such as space based remoting to optimize the data access of the application and use our

    
    
  • Data Grid Querying, Revisited

    There has been a great deal of talk lately about the new EHCache cache querying capabilities and the advantages of real-time analytics through in-memory cache querying. I find that rather odd since extensive querying and processing capabilities have been around for years with in memory data grids like GigaSpaces XAP, Oracle Coherence, Gemstone GemFire and more recently Hazelcast and GridGain. So I don’t really understand the big fuss around EHCache finally supporting it….

    But that’s actually a great opportunity to revisit some of the work we’ve done in our recent 8.0 release in the context of querying. There are two main features we’ve introduced in 8.0 that take data grid querying to the next level.

    Complex Object Querying

    The first one is complex object graph querying. Simply put, you can now index and any type of property, at any nesting level, of your data grid objects: primitive types, user defined types, or collections/arrays of either.
    Think of an Author object, which has a collection of books, each of them containing a collection of user reviews.
    Here are just two examples of what you can achieve with XAP 8.0:
    • List all the Authors that wrote at list one sci-fi book:


    Author[] authors = gigaSpace.readMultiple(new SQLQuery<author>(Author.class,
    "books[*].genre = ‘Sci-Fi’ ORDER BY name",Integer.MAX_VALUE);

    • List all the Authors who have at least one book on which your friend on Facebook commented:


    Author[] authors = gigaSpace.readMultiple(new SQLQuery<author>(Author.class,
    "books[*].comments[*].username= ?", “myFacebookFriend”, Integer.MAX_VALUE);

    This goes hand in hand with our new Document support, so you can apply the above to schema free documents as well as just plain Java or .Net objects.

    GigaSpaces JPA

    The second feature is our all new JPA support. We believe this to be a major step towards ease of use and standardization of distributed data store access.

    There have been a lot of discussions in the developer community about how the “classic” querying and interaction models (such as SQL/JDBC and JPA) can be mapped to the world of distributed data stores (which in memory data grids are a part of).

    When it comes down to querying, each distributed data store defines its own querying language and semantics. Some are completely proprietary (e.g. EHCache’s new query DSL, or MongoDB’s query syntax), some are modeled after standard SQL to some extent or the other (e.g. GigaSpaces’ native querying support, Coherence’s recent QL, or GridGain’s query language).
    All of these seem be solid query implementations (naturally you can guess which one I like best :) ).

    But when developing to each of those products, you need to learn their interaction model, data access semantics (such as transaction management) and of course querying language.

    The first take at bridging the two worlds, and IMO pretty successful one considering the inherent difficulties in bridging the two models (see this presentation I’m giving at QCon London in two days), was actually done by Google almighty with the JPA support in AppEngine.
    Although not 100% standard (actually not even close), it gives you as a developer a very easy and familiar way to implement scalable data access on top of their BigTable data store, and a very clear migration path for putting your apps on AppEngine, should you choose to do so. It also makes your code a lot more portable since JPA, even a partial version of it, is still way more standard and portable than any proprietary API.

    GigaSpaces JPA – Design Principles

    When we initially thought of implementing a JPA interface to our data grid, we had the following goals in mind:

    • Make our user’s life easier by providing a standard way for the to interact with the data grid that will allow them to easily get up to speed with new applications, and port existing JEE applications more smoothly and quickly.
      For that, we created a thin layer on top of the excellent OpenJPA framework so that configuring a GigaSpaces EntityManagerFactory is a breeze if you’re already into JPA in general and OpenJPA in particular. We also managed to support a nice set of features from the JPA specification (actually more extensive than Google’s AppEngine JPA) so that most of the stuff users actually do with JPA is covered. Naturally, this is just our first take at this huge project, and we’ll add more and more capabilities as we move forward.
    • Enable our users to leverage the power and scalability of the data grid to scale their data access, even when they’re using JPA (which was originally designed for a centralized data model). This means exposing content based routing and data grid indexing to their JPA domain model, and abstracting away cluster wide transactions and queries.
    • Protect our users from making wrong implementation decisions when modeling and accessing their distributed data. In Google AppEngine’s terminology, this means supporting Owned Relationship only such that object graphs are not scattered across many nodes and are always limited to a single node.
    • Allow our users to use our powerful native APIs for functions that are not covered by the JPA specification, e.g. event handling, distributed task execution, and more. So it actually means that you can use the JPA API, while still operate on the same data model and entities via our native POJO based API. This is a very powerful concept that covers not only JPA but all of our data access APIs, we call Same Data, Any API and it means that you can operate on the same data using a variety of APIs – besides our native POJO API and JPA. For example, you can read a JPA entity as a document (in case you want to treat it in a more loosely flexible manner, or use our C++ client side API from native clients to read this data.

    See for Yourself

    We have just published an comprehensive tutorial that explains the principles of the our JPA implementation using the good old Spring PetClinic sample app (we’ve added our own flavor to it :) ). It explains the data model considerations and shows how take advantage of data grid features such as space based remoting to optimize the data access of the application and use our

    
    
  • Data Grid Querying, Revisited

    There has been a great deal of talk lately about the new EHCache cache querying capabilities and the advantages of real-time analytics through in-memory cache querying. I find that rather odd since extensive querying and processing capabilities have b…

  • Productivity vs. Control tradeoffs in PaaS

    Gartner published recently an interesting paper: Productivity vs. Control: Cloud Application Platforms Must Split to Win. (The paper requires registration.) The paper does a pretty good job covering the evolution that is taking place in the PaaS market toward a…