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).
Related
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.
I am using Intellij IDEA to develop my applications and I use glassfish for my applications.
When I want to run/debug my application I can configure it from Glassfish Server -> Local and define arguments at there. However there is another section instead of Glassfish Server, there is a Remote section for configuration. I can easily configure and debug my application just defining host and port variables.
So my question is why to need for Glassfish Server Local configuration(except for when defining extra parameters) and what is difference between them(I mean performance or etc.)?
There are a number of development work-flow optimizations and automation that can be performed by an IDE when it is working with a local server. I don't have a strong background in IDEA, so I am not sure which of the following they may have implemented:
using in-place|exploded|directory deployment can eliminate jar/war/ear creation in the IDE and deconstruction in the server. This can be a significant time saver.
linked to 1 is smarter redeployment. In some cases, a file change (like changing a jsp or an html file) does not need to trigger redeployment.
JDBC driver integration allows users to configure their IDE to access a DB and then propagates that configuration (which usually includes driver jars, etc.) into the server's classpath as part of deployment of an app.
access to server log files during deployment and execution.
The ability to start and stop the server... even today, you do need to restart GlassFish sometimes.
view the generated Java sources of a JSP.
Most of these features are not available with a remote server and that has a negative effect on iterative development since the break between edit and validate can be fairly long.
This answer is based on my familiarity with the work that we have done for the NetBeans/GlassFish integration. The guys at IntelliJ are smart, so I would not be surprised if they have other features that are available when you are working with a local server.
Local starts Glassfish for you and performs the deployment. With Remote you start Glassfish manually. Remote can be used to debug apps running on another machines, Local is useful for development and testing.
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 would like to override the portion of JBoss that loads JDBC connection information from the XML config file. I would like to continue using the rest of JBoss's connection pooling/caching features. I just want to load the connection data from another source.
Which MBean should I be implementing and how do I configure the override in JBoss?
The JBoss -ds.xml descriptors actually cover a multitude of sins. If you look on the JBoss JVM console, you'll find 4 or 5 MBeans there for each data source. You could potentially do this programmatically, but I wouldn't give good odds on your chances.
My suggestion would be to use a 3rd-party connection pooling library (e.g. Commons DBCP). Define the pool using that, and then bind the resulting DataSource to JNDI. CLient application using the pool shouldn't know any difference.
Currently the major means of connecting Flash AS2/AS3 to a MySQL database are:
Flash > PHP > MySQL -- "secure code" in PHP Scripts
Flash Asql or Assql > MySQL -- "secure code" in MySQL Stored Procedures
The second approach is newer, but directly connects to a MySQL DB using binary sockets and ByteArrays.
In which case would the "secure code" be less accessible and therefore more secure?
I'm assuming stored procedures cannot be accessed via FTP so that might be harder to break into?
Stored procedures can only be accessed by someone with the correct database credentials so they will be secure assuming no one cracks your Data Base password. You know it might actually be that the PHP code is more secure as you can hold the Data Base password on the server instead of in the host app.
I suppose you can always decompile flash and try to locate the password in the host app because with asql the password will be stored in the host app, instead of on the server hidden behind PHP
I'm not sure asql would work for users behind the proxy, so I wouldn't use it for website. Approach with PHP in the middle seems to be better and you can (and should) model api for your application that is different from your DB structure.
It appears that both assql and binary sockets are synchronous links that use a socket connection to the database. Which might be great for an AIR application, but for a browser app might be highly problematical. Is this for sure what you want? Your question about access through stored procedures gives me the idea you aren't too sure about this stuff.
In fact, using PHP properly will likely be easier for building a solid abstraction and security indirection barrier between your app (and its host) and the database.
EDIT:
Web clients and servers use the http protocol to communicate. This is called a "stateless" and "connectionless" (which is only kinda true) protocol because the connection between the two only lasts as long as it takes for the client to request everything and the server to send back everything. The obvious benefit is that the server only knows about each client for a very brief period of time.
A socket (in the sense these two protocols use one) is a permanently established connection between the client and server that persists until one end or the other closes it (connection-based); and both sides know the state of the connection (open or closed). So they tie up a lot of host resources per client for a long time, and things get wacky when the connection breaks. Big difference, and it can't be run through the ports supporting web pages - another port needs to be provided (sometimes two) on the host and the client to support the socket.