Forum: Building VoltDB Clients

Post: Web apps and client connections

Web apps and client connections
McG
Mar 3, 2011
In the simplest setup where there is just 1 server on localhost...
The documentation seems written for a single-threaded clients, but I am a little unclear how
to use safely with a multi-threaded client.
Some questions:
1. Is the client factory MT Safe?
2. Are the connections upon a client MT safe? (i.e. many threads can call stored procs using same client concurrently)
3. If it is a MT client, and 1 thread per request - should clients be re-opened and closed per each thread_request or should clients left open until the app is shutdown?
4. What is the overhead of opening/closing a client connection? Am I creating a new server socket connection each time or is the physical connections managed internally by the factory? In other words, does close() close the socket?
5. what is the spec behavior when a client is closed while there are outstanding async requests? Exception thrown by close() invocation?
I read in the forum somewhere that JEE and Spring transactions, etc. have no effect. I think it would be nice to put that in documentation somewhere as it could be a very painful discovery should someone not happen upon that info.
It would be nice if the documentation was crystal clear on MT clients. Having a simple jetty web app as one of you examples would make this easier for a lot of new users I think.
Hi McG, Good catch! I looked
aweisberg
Mar 3, 2011
Hi McG,
Good catch! I looked over the docs and they don't do a good job of pointing out that the Java client is thread safe. I created https://issues.voltdb.com/browse/ENG-1019 to track documentation and example improvements for this issue.
1. Yes
2. Yes
3. You should use one client per process and only close it when the process shuts down. The client creates a dedicated thread and opens a selector so it is relatively heavyweight.
4. The factory doesn't create a client that is connected to anything. You are creating a opening/closing one or more sockets as well as creating/terminating a thread. The Java API doesn't support closing individual connections within a client instance, only closing all of them along with the client instance.
5. There is no exception if there are outstanding requests. The state of the outstanding requests is undefined. They may not have even made it to a server. If you care about outstanding transactions you should call drain() before close().
Can you explain what you mean by JEE and Spring transactions? Why would there be an expectation that those frameworks would extend to an independent system like VoltDB?
Thanks,
-Ariel
re: MT-Client
McG
Mar 3, 2011
Hi McG,
Good catch! I looked over the docs and they don't do a good job of pointing out that the Java client is thread safe. I created https://issues.voltdb.com/browse/ENG-1019 to track documentation and example improvements for this issue.
1. Yes
2. Yes
3. You should use one client per process and only close it when the process shuts down. The client creates a dedicated thread and opens a selector so it is relatively heavyweight.
4. The factory doesn't create a client that is connected to anything. You are creating a opening/closing one or more sockets as well as creating/terminating a thread. The Java API doesn't support closing individual connections within a client instance, only closing all of them along with the client instance.
5. There is no exception if there are outstanding requests. The state of the outstanding requests is undefined. They may not have even made it to a server. If you care about outstanding transactions you should call drain() before close().
Can you explain what you mean by JEE and Spring transactions? Why would there be an expectation that those frameworks would extend to an independent system like VoltDB?
Thanks,
-Ariel


First, thanks Ariel for a quick response!
>Can you explain what you mean by JEE and Spring transactions?
>Why would there be an expectation that those frameworks would extend
>to an independent system like VoltDB?
Since transactions apply to in-memory datastores like H2, HSQL, oracle times 10, and every relational database, plus JMS, etc. I imagine most coming from java will probably be expecting container managed transactions to apply to volt I suspect. Either way, a page of doc on how to setup volt with Spring and some explanation of what it doesn't do with container transactions might lower the barrier to entry a little.
McG
Hi McG, I reviewed the docs
aweisberg
Mar 10, 2011
First, thanks Ariel for a quick response!
>Can you explain what you mean by JEE and Spring transactions?
>Why would there be an expectation that those frameworks would extend
>to an independent system like VoltDB?
Since transactions apply to in-memory datastores like H2, HSQL, oracle times 10, and every relational database, plus JMS, etc. I imagine most coming from java will probably be expecting container managed transactions to apply to volt I suspect. Either way, a page of doc on how to setup volt with Spring and some explanation of what it doesn't do with container transactions might lower the barrier to entry a little.
McG


Hi McG,
I reviewed the docs and you are right that we don't make clear that the unit of transaction is the stored procedure. This precludes integration with external transaction management frameworks because the decision to commit/rollback has to be made in the procedure.
I created https://issues.voltdb.com/browse/ENG-1029 to track the doc update for this issue.
I don't have any familiarity with Spring so I am not sure how you would use it with VoltDB without implementing the various interfaces Spring defines.
Ariel
Sxandy
Oct 27, 2014
Running with JDBC java.sql.Connection directly works in both Groovy and Java when invoking createStatement().
The problem seems centered around which createStatement(...) is called by Groovy. Does the VoltDB connection support all Connection.createStatement methods = specifically those that pass resultSetType and resultSetConcurrency? When I try those, using java.sql.Connection, it failed for both Java and Groovy.
Here is example that fails in either Groovy or Java:
Statement st = con.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY);
vtkstef
Oct 27, 2014
Hi Scarlett,

As of now VoltDB's JDBC driver only supports ResultSet.TYPE_SCROLL_INSENSITIVE for result set type, and ResultSet.CONCUR_READ_ONLY for result set concurrency. Is using the VoltDB client from groovy something you could entertain?

Ciao
Stefano