i want to use multiple connection to the couchbase server. Please suggest if any connection pool library available for libcouchbase client.
I don't aware of such libraries, but it shouldn't be hard to write your own. For example, we do pooling in our pillowfight utility:
https://github.com/couchbase/libcouchbase/blob/master/tools/cbc-pillowfight.cc#L251
It isn't absolutely portable, because it is relying on pthreads, though.
Related
I am practicing writing an app which use MySQL to manipulating data.
My concern is if my client machine doesn't have have MySQL pre-installed, it's not be able to run my app, is it?. So is there anyway to embed the database server right into the app, or to run the app without the data server. I wonder how all the softwares out there manipulates data. It's not like we need to install some kind of database server before install the app.
MySQL is a client/server database engine, which means that you must install the client and server separately from each, and they communicate over some kind of network protocol.
If you want to deploy a stand-alone application, you are probably better off using a library like SQLite, which gives you as much of the functionality of a SQL database as you are likely to need in such an app, but instead operates on local files and doesn't require installation of a separate server.
You can embed MySQL in your application, see MySQL as an Embedded Database for details.
Your application could work with the remote database, when configuring database connection you should set your DB server IP address(host), port and login credentials. so in order to write application which is dealing with data manipulation, you need to connect to any database instant.
If you are working on client-server application, MySQL database may be accessed either by means of MySQL (this solution may be suitable for internal networks), or through some database-side service, which can provide some API and which can be accessed from client via some application-level protocol (for example, XML-RPC).
If you are working on client application, there are other database solution, which can be used in stand-alone software: SQLite, Derby. As an alternative to database approach, you may consider storing data in XML / YAML format.
I suggest to wrap db layer in you application witch simple interface provided for all operations performed on the database. In this way, you will not have to go into the details of the atomic operations on the database and through unified interface, you can create several different classes which will be responsible for access to different databases in the same way (the same interface). These classes should realize the interface and implement all necessary methods inside (for example ADO). Now your db layer can be visible in all program it the same way. Wrapped class can realize singleton desing pattern and can be used as one instance enywhere in your application. Universal class design (interface) gives you many benefits such as the possibility of substitution on another layer if necessary (switch to a totally different db).
Is there any solution for running these kind of operations on DreamHost or other shared hosting environments where I don't have access to tweak apache?
You certainly can, but as long as Apache HTTP server doesn't provide non-blocking IO capabilities (and each polling connection has a server thread associated to it), you'll be running out of memory very fast (after 2-3k connections).
If you meant Apache Tomcat, NIO is turned off by default, and you need to have access to configuration files in order to change this.
I am not familiar at all with connection pooling library. I've just discovered it through this blog article) and I am not sure that I should use one in my web application based on grails/hibernate/mysql.
So my question is simple : in which situations would you suggest to integrate a connection pooling library into a grails application? Always, Never or only over some connections threshold?
P.S. : If you have ever used successfully C3P0 in your web application, I will greatly appreciate to hear your feedback (in terms of visible positive effects).
Regardless of which pooling implementation, you should use a connection pool always in your web application. Open a connection with the database is a very expensive task and being able to reuse a already existing and idle connection greatly improves your site performance.
A connection can be managed by the application server (Tomcat, JBoss, Glassfish...) or by your application. The latter is easier to setup but it's hard to customize per deployment. Configuring a connection pool on the application and setting your site to consume it makes easy to the fine tune the connection pool parameters, like: minimum connections to keep open, max idle time and so on.
My experience with this is pretty limited, but I ended up using C3P0 for the simple reason that Hibernate does not seem to handle MySQL restarts. I got a "Broken pipe" every morning because our hosting service restarted MySQL every night.
I googled it and the only advice I could find was to use... the connection pool of the app server or C3P0. For me, the latter works just fine.
I always use a connection pool for two reasons:
Because opening connections is an expensive operation
It's dead-simple to set one up to work transparently, so there's no real advantage to not using one.
If you're already using hibernate, just modify your hibernate.cfg.xml's connection.provider_class to use org.hibernate.connection.C3P0ConnectionProvider and throw the c3p0 jar file into your servlet's WEB-INF/lib folder. Done.
If you're using JNDI and a GlobalNamingResources declaration, modify the type property to point to com.mchange.v2.c3p0.ComboPooledDataSource and throw the c3p0 jar into Tomcat's /lib folder. Done.
C3P0 is a very decent pool but I would still recommend to use the connection pool of your app server or servlet engine and to configure Grails to use it via a regular DataSource. Use a stand-alone connection pool when you can't do that (in which case C3P0 is a good choice).
I have a C application using the MySQL library for database access.
Is there a standard way to implement database connection pooling for such an application?
The C connector doesn't appear to support it.
The Zild Database Library, "a thread-safe high level multi-database connection pool library", looks very promising.
Previously I suggested that
SQL Relay could be used to do this, amongst many other useful things, such as
client-side caching
load-balancing across database instances
translating between different database access APIs
If the MySQL library is dynamically linked this can be done without recompiling the application.
When I last looked in 2009, the mailing list suggested SQL Relay might not be fully ready for production use, but that appears to have changed.
I am taking on a legacy project in which database management was handled over the internet using an ODBC connection. The legacy program has recently been rewritten in C#. We are currently discussing how to improve the program and I am a bit uncomfortable with using ODBC to connect to the database. I have written routines to connect to a server using sockets and POST, PUT, and GET commands combined with cgi or php scripts and have read extensively about the AJAX paradigm which I see as the way forward. My colleague insists on using ODBC. What are the pros and cons of using an ODBC connection vs. a more modern approach?
Database-to-application protocols were never designed to be used over the internet. They are too chatty and difficult to secure. If you have the opportunity to do so, then you should consider encapsulating the database behind a properly-secured web service.
those who don't know networking are doomed to reinvent it on port 80
there's nothing 'modern' about HTTP over ODBC. just be sure to wrap it in SSL and/or a VPN and use sensible access controls.
it will be a lot more efficient than HTTP, which wasn't designed for this. at the very least, HTTP commands add a lot of overhead for each operation. ODBC will get you far better latency (which is critical in client-driven DB designs)
How about using ODBC with a modern approach, web services. There are many advantages to this approach. For example:
Multiple client programs can use a single instance of the web service to
access data. There is no need to
write database related code in each
individual application.
Users need to install ODBC drivers and configure ODBC data
sources only on the server machine
that hosts the web service. Client
programs can be running on other
machines over the network.
Client programs are not limited to .NET or Windows platform. All they
have to do to access database is call
a web service.
Database connections can be shared among different client
programs.
Access to databases can be controlled and monitored from a
central location (the web service).
Of course, there are some security issues and limitations to the complexity of your queries.
I had something similar in my office. They had lots of machines with VB.NET apps hitting the local database (regularly got it stuck with too many unused connections) and some web services that contacted an external database through an SSH/SSL tunnel.
We didn't really have a lot of problems with the external database unless the tunnel went down which was rare. You can probably also set up a VPN.
If you are interested in using AJAX/JSON/REST technologies to communicate with a database, you can use an abstraction layer like DBSlayer.
Using a TypeIV "direct" database driver like the System.Data.SqlClient namespace for C# ,or a JDBC driver for Java, is 2-3 times more efficient (better performance) than going through the ODBC layer.
I would avoid ODBC because its slower and I think its not any easier.