Can I use GigaSpaces/JDBC as an alternative to JDBC complaint DB?

It depends. The GigaSpaces Data Grid is not a full-fledged relational database and we do not support the full SQL92 standard. However, our SQL support is extremely useful for customers who want simple integration with extisting application and to execute complex queries on a Space (e.g. ranges).

GigaSpaces' JDBC and SQL support is centered around Space-Based Architecture and the main motivation behind our SQL query support was to enable more sophisticated query capabilities to the space.

The SQL query support is provided in two flavors: 1. JDBC interface 2. SQLQuery interface (the preferred approach)

The JDBC interface is mostly used to enable access to the space through standard SQL tools and programming interfaces - i.e. you can write SQL commands against the space and that code would in many (simple) cases be compatible with other SQL implementations.

Note that this is a unique feature to the GigaSpaces distributed caching product. So far this feature has been very popular with many of our accounts. We use those capabilities internally to enable content browsing of the space/cache and running queries against it.

One of the interesting aspects of this approach is that you can write data through the space API or even JMS API and browse through that data using a JDBC browser in real time. We use the Space as the underlying engine for implementing the SQL commands to enable the API interoperability mentioned above. We are gradually enhancing the support within the Space to support more SQL commands.

Porting existing JDBC code to the space is certainly doable (but would require some level of adaptation depending on the specifics of the case and the complexity of the SQL queries) and - for legacy applications - may still be easier then porting existing code to leverage the Space technology directly. Since we support only part of the SQL syntax this path should be taken with this extra caution and would normally requires close support from GigaSpaces technical team.

The list of supported SQL features is provided below:

The second option (SQLQuery) approach is more popular with applications that require high performance and are OO in nature since it combines the benefits of OOP and the Relational world. In this approach you can write and read objects directly and still perform SQL query against them (essentially the WHERE clause) without adding any O/R mapping complexity. It is also the most efficient approach in terms of performance. For more information, see:

{quote}This thread was imported from the previous forum. For your reference, the original is [available here|]{quote}

asked 2006-03-17 19:14:00 -0500

gbarnea's avatar

updated 2013-08-08 09:52:00 -0500

jaissefsfex's avatar
edit retag flag offensive close merge delete