JDBC driver

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

JDBC driver

Valentin Kulichenko
Igniters,

Current version of JDBC driver is still based on legacy thin client and I
think it's wrong. First of all, the thin client as deprecated long time ago
and is not really supported. Second of all, it's much slower than native
query API, which makes the driver useless in most cases.

I suggest to replace thin client with an embedded client node. This should
be pretty easy to implement and will give serious performance improvement.
By I have a couple of concerns about configuration:

   - How can we provide configuration file path? JDBC is commonly
   configured with a single URL. But if the file path is a parameter if this
   URL, it needs to be encoded, right? Sounds like usability issue...
   - Do we need to preserve compatibility? We currently have a bunch of
   configuration parameters which are specific to thin client. Removing the
   client means removing them as well. Do we need two have two modes with thin
   client as a default one for now?

Please share your thoughts.

-Val
Reply | Threaded
Open this post in threaded view
|

Re: JDBC driver

Andrey Gura
Valentin,

I think that JDBC URL parameter for configuration file it is ok.

I see three compatibility related problems (except obvious change in URL
configuration):

1. Java client supports client credentials as simple alternative to SSL.
2. HTTP access can be usefull in some cases.
3. Access to local caches on specified node.

From my point of view, all of them are not critical (especially 3rd item).
But somebody can have another opinion.

Anyway, we can support two different modes if needed.

I created ticket https://issues.apache.org/jira/browse/IGNITE-1250 and
started work.

It would be great if you or somebody else give me answers to my questions
in comments to the ticket.

Thanks.


On Thu, Aug 6, 2015 at 8:54 PM, Valentin Kulichenko <
[hidden email]> wrote:

> Igniters,
>
> Current version of JDBC driver is still based on legacy thin client and I
> think it's wrong. First of all, the thin client as deprecated long time ago
> and is not really supported. Second of all, it's much slower than native
> query API, which makes the driver useless in most cases.
>
> I suggest to replace thin client with an embedded client node. This should
> be pretty easy to implement and will give serious performance improvement.
> By I have a couple of concerns about configuration:
>
>    - How can we provide configuration file path? JDBC is commonly
>    configured with a single URL. But if the file path is a parameter if
> this
>    URL, it needs to be encoded, right? Sounds like usability issue...
>    - Do we need to preserve compatibility? We currently have a bunch of
>    configuration parameters which are specific to thin client. Removing the
>    client means removing them as well. Do we need two have two modes with
> thin
>    client as a default one for now?
>
> Please share your thoughts.
>
> -Val
>



--
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com