I have a grails web application which is connecting to a Postgres database. I'm concerned that the code is opening multiple database connections.
How can I find out how many connections it is holding during a request?
There's a lot of magic going on in there with GORM etc and I'm not sure how it's managing its connections.
It's managed by the dataSource bean, which is a javax.sql.DataSource. Unfortunately this interface is very basic, with only 4 methods - 2 getConnection() methods (one with and one without a username/password) and unwrap and isWrapperFor from its parent interface. The actual implementation classes typically have many different methods for configuration and monitoring, but there isn't really any standard, and definitely no interface.
If you're using a recent version of Grails and haven't reconfigured anything, the backing implementation is the Tomcat JDBC Pool, which doesn't depend on Tomcat but was written by a Tomcat committer. You can't just cast that bean to the pool implementation class however, because Grails wraps the actual datasource instance in two proxies. Fortunately the "real" instance is easy to get to - dependency-inject the dataSourceUnproxied bean in a service or wherever you wanted to look at usage:
def dataSourceUnproxied
and then you can call any of its methods (see the Javadoc for what's available)
It's not needed for Groovy of course, but if you want IDE autocompletion add this import
import org.apache.tomcat.jdbc.pool.DataSource
and cast it and call the methods on that, e.g.
DataSource tomcatDataSource = dataSourceUnproxied
log.debug "$tomcatDataSource.active active (max $tomcatDataSource.maxActive, initial $tomcatDataSource.initialSize), $tomcatDataSource.idle idle (max $tomcatDataSource.maxIdle, min $tomcatDataSource.minIdle)"
Related
I'm reading the Grails docs on services which make numerous mention of transactions/transactionality, but without really defining what a transactional service method really is.
Given the nature of services, they frequently require transactional behaviour.
What exactly does this mean? Are transactional methods only those that use JPA/JDBC to communicate with a relational DB, or do they apply to anything covered by JTA?
Is there any reason why I just wouldn't make a service class #Transactional in case it evolves to some day use a transaction? In other words, are there performance concerns to making all service methods transactional?
Grails services are transactional by default - if you don't want a service to be transactional, you need to remove all #Transactional annotations (both Grails' #grails.transaction.Transactional and Spring's #org.springframework.transaction.annotation.Transactional) and add
static transactional = false
If you haven't disabled transactions with the transactional property and have no annotations, the service works the same as if it were annotated with Spring's annotation. That is, at runtime Spring creates a CGLIB proxy of your class and registers an instance of the proxy as the Spring bean, and it delegates to an instance of your actual class to do the database access and your business logic. This lets the proxy intercept all public method calls and start a new transaction, join an existing one, create a new one, etc.
The newer Grails annotation has all of the same settings as the Spring annotation, but it works a bit differently. Instead of triggering the creation of a single proxy, each method is rewritten by an AST transform during compilation, essentially creating a mini proxy for each method (this is obviously a simplification). This is better because the database access and transaction semantics are the same, but if you call one annotated method from another annotated with different settings, the different settings will be respected. But with a proxy, it's a direct call inside the delegate instance, and the proxy is bypassed. Since the proxy has all of the logic to create a new transaction or use other different settings, the two methods will use the first method's settings. With the Grails annotation every method works as expected.
There is a small performance hit involved for transactional methods, and this can accumulate if there are a lot of calls and/or a lot of traffic. Before your code runs, a transaction is started (assuming one isn't active) and to do this, a connection must be retrieved from the pool (DataSource) and configured to turn off autocommit, and make the various transaction settings (isolation, timeout, readonly, etc.) have to be made. But the Grails DataSource is actually a smart wrapper around the "real" one. It doesn't get a real JDBC Connection until you start a query, so all of the configuration settings are cached until then, and then "replayed" on the real connection. If the method doesn't do any database work (either because it never does, or because it exits early based on some condition before the db access code fires), then there's basically no database cost. But if it does, then things work as expected.
Don't rely on this DataSource proxying logic though - it's best to be explicit about which services are transactional and which aren't, and within each service which methods are transactional and which aren't. The best way to do this is by annotating methods as needed, or adding a single annotation at the class level if all methods use the same settings.
You can get more info in this talk I did about transactions in Grails.
First, if your performance concerns are due to the fact your services are transactional then you have reached nirvana. I say this because there are going to be plenty of other bottle necks in your application long before this is a major (or even minor) concern. So, don't fret about that.
Typically in Grails a transaction relates to the transactional state of a database connection or hibernate session. Though it could be anything managed by the JTA with the proper Spring configuration.
In simple terms, it's usually means (by default) a database transaction.
I am using the Grails Rabbitmq Native plugin. When I launch the application, I don't want the RMQ consumers to be automatically started, so in my Config.groovy I have defined:
rabbitmq.enabled == false
The code within doWithSpring() (https://github.com/budjb/grails-rabbitmq-native/blob/master/RabbitmqNativeGrailsPlugin.groovy#L114) means that certain wiring isn't carried out if this flag is false.
At some point, I want to be able to start the RMQ system up. I'd like to call a method defined within the plugin class, such as restartRabbitContext() (https://github.com/budjb/grails-rabbitmq-native/blob/master/RabbitmqNativeGrailsPlugin.groovy#L231) to start up the RMQ consumers. I think I will need to carry out some of the wiring myself.
Is there a way to do this? What is the import required to be able to access the plugin class's methods?
Your best bet is to use the GrailsPluginManager to access your plugin by name using getGrailsPlugin. From there you should be able to access the plugin as a GrailsPlugin and access the public methods defined in the plugin itself.
The GrailsPluginManager can be obtained though the grailsApplication such as: grailsApplication.pluginManager. In the very rare event you can't use DI you can always fall back to Holders to get to the GrailsPluginManager (though this is a very rare case).
Mostly static, frequently accessed domain classes such as countries and currencies can benefit greatly from caching.
class country {
:
static mapping = {
cache usage: 'read-only', include: 'non-lazy'
}
}
However, once in a while, a new country is added or an existing one modified in a multi-server environment. The solution we are looking for is a cache timeout, so that after a configurable time per domain class, e.g. 10 minutes, it re-reads the data when a get is requested.
Currently, the only option is if you cache something, you have to restart all the servers. We don't want the complexity of a distributed cache, which broadcasts changes, just a cache aging option on a per domain basis.
Is this possible with grails 2.4.4, or do we need to implement our own caching layer? With MyBatis specifying the max age (aka cache timeout) is easy - hope grails has an undocumented feature for this.
Restarting the server is very far from being the only option.
The configuration options for caching in the mapping block are quite limited, but that's at least in part because there's no standard configuration API, so you need to do it differently depending on the provider.
The default implementation is Ehcache, and it's pretty simple to configure. If Ehcache finds an ehcache.xml file in the root of the classpath, it will use that instead of its defaults. Non-Java files in src/java and non-Java/non-Groovy files in grails-app/conf are copied to a directory that's in the classpath during compilation, so putting your file there is the best bet for making it accessible.
Use this heavily commented example ehcache.xml file to get started.
If you want to remove one or more cached instances, Hibernate has an API for that. There are several "evict" methods that you can call on the sessionFactory bean, e.g. sessionFactory.evict(Book) removes all cached Book instances, sessionFactory.evict(Book, 5) removes the cached Book with id 5, etc.
There's a lot of relevant info in the slides from this SpringOne/2GX talk including configuring Ehcache and working with the 2nd-level cache API.
In a java web app, I need to call a remote soap service, and I'm trying to use a CXF 2.5.0-generated client. The soap service is provided by a particular ERP vendor, and its wsdl is monstrous, thousands of types, dozens of xsd imports, etc. wsdl2java generates the client ok, thanks to the -autoNameResolution flag. But at runtime it retrieves the remote wsdl twice, once when I create the service object, and again when I create a port object.
MyService_Service myService = new MyService_Service(giantWsdlUrl); // fetches giantWsdl
MyService myPort = myService.getMyServicePort(); // fetches giantWsdl again
Why is that? I can understand retrieving it when creating myService, you want to see that it matches the client I'm currently using, or let a runtime wsdl location dictate the endpoint address, etc. But I don't understand why asking for the port would reload everything it just went out on the wire for. Am I missing something?
Since this is in a web application, and I can't be sure that myPort is threadsafe, then I'd have to create a port for each thread, except that's way too slow, 6 to 8 seconds thanks to the monstrous wsdl. Or add my own pooling, create a bunch in advance, and do check-outs and check-ins. Yuck.
For the record, the JaxWsProxyFactoryBean creation route does not ever fetch the wsdl, and that's good for my situation. It still takes a long time on the first create(), then about a quarter second on subsequent create()s, and even that's less than desirable. And I dunno... it sorta feels like I'm under the hood hotwiring the thing rather than turning the key. :)
Well, you have actually answered the question yourself. Each time you invoke service.getPort() the WSDL is loaded from remote site and parsed. JaxWsProxyFactoryBean goes absolutely the same way, but once the proxy is obtained it is re-used for further invocations. That is why the 1st run is slow (because of "warming up"), but subsequent are fast.
And yes, JaxWsProxyFactoryBean is not thread-safe. Pooling client proxies is an option, but unfortunately will eat a lot of memory, as JAX-WS runtime model is not shared among client proxies; synchronization is perhaps better way to follow.
I am developing a J2EE application on Glassfish 3.1 which will use one external library that relies heavily on URLs. The URLs will use a custom protocol (e.g. db:123 where 123 is ID of a record in a database). I am having doubts on how to implement the URL protocol handler (and its URLConnection implementation), because this protocol handler will use EJBs to fetch data from the database.
The db protocol handler needs to be registered globally at the moment of JVM startup through -Djava.protocol.handler.pkgs flag. (I couldn't find a better way to do this in Glassfish.) Anyway, because it is registered at JVM startup, it has no knowledge of any EJBs that that it may call at the moment of opening URL streams. So what I did is create a singleton registry class to which database handlers can be registered. This registry is used by URLConnection whenever a stream is requested (it will search the registry for a database handler and use it to fetch data).
Then, an EJB will register itself as database handler in a #PostConstruct method. This way, any time a db:XXX URL is used, EJBs will be called indirectly to fetch the data.
Somehow I feel that this design is a bit dirty, but I'm very limited because of custom URL handlers. If you have any suggestions or tips that you can give me, that would be great.