I can't use built-in connection pooling of SQLite. It doesn't work with WPF apps. It is stated in the source code of SQLiteConnectionPool class.
I would like to implement my own connection pool for SQLite connections using Linq2DB DataConnection class. What is the best way to implement this?
I can see DataContext doesn't have constructor which accept DataConnection. Should roll my own implementation of IDataContext which uses ConnectionPool internally to get the connection?
If you want to control connection creation, I would recommend to subclass SQLiteDataProvider and override CreateConnectionInternal method to provide your own logic for new connection creation.
This will cover all cases when linq2db needs to create connection, not just DataConnection or DataContext calls.
PS: not sure which statement you mean, as I don't see any WPF or cannot notes in SQLiteConnectionPool's code.
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 have a ruby on rails application that takes a user http request, connects to the database, and sends back the response. To make the application faster, I would like to implement the db connection pool to avoid creating a new connection every time. I tried looking into the connection pool library, but did not fully grasp how to use it. Any help or pointers would be highly appreciated? Thanks.
ActiveRecord is the default ORM library that Rails uses and it automatically handles connection pooling for you so unless your using some other library you don't need to do anything.
Some of the pool options are configurable if you feel like you need to mess with them but I doubt you would http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/ConnectionPool.html
I'm using Powershell v2.0, question is in the title. I'm having to use the old school ADOB.Connection (not the OLEDB provider) to open a Jet DB file (.mdb). The reason is simple, the ADODB.Connection exposes properties I need access to that the OLEDB provider doesn't.
I'm opening the DB via ADOB.Connection to query for some information, and then I'm trying to compact the DB using JRO.JetEngine. The issue is that I keep getting an error about the Jet DB being locked.
I'm explicitly calling Close on it, and setting the variable to $null, and still experiencing that issue. My best guess is that ADODB.Connection is using connection pooling, and so is not releasing the resources the way it should be.
According to http://support.microsoft.com/kb/191572, the call to close() should be enough, but it doesn't seem to be working.
Is there a way for me to explicitly specify no connection pooling when creating ADODB.Connection objects?
In the link you provided, it is said that calling to close returns the connection to the pool:
2.What statement returns the connection to the pool?
2.Conn.Close
You might need to destroy/dispose the ADODB.Connection object, so that it is removed from the pool, or, if you are using OLE DB as the provider, configure the OLEDB Services, as explained here:
Enabling OLE DB Resource.
Pooling Resource pooling can be enabled in
several ways:
For an ADO-based consumer, by keeping one open instance of a
Connection object for each unique user and using the OLEDB_SERVICES
connection string attribute to enable or disable pooling. By default,
ADO attempts to use pooling, but if you do not keep at least one
instance of a Connection object open for each user, there will not be
a persistent pool available to your application. (However, Microsoft
Transaction Server keeps pools persistent as long as the connections
in them have not been released and have not eventually timed out.)
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.
I'm using grails but I have lot's of stored procedures I'm trying to call from groovy.Sql.newInstance...
In all the examples I've found I never see anyone actually calling close on the connection. But when I tried running a bunch of methods within one response that each uses its own call to newInstance, then it got an error that there were too many connections. That leads me to believe that it isn't pooling the connections. That's a bummer. So do people create one connection and pass it around? Does grails and groovy close the connection at the end of the request?
I don't think that the connection is automatically closed after a request (which wouldn't be cool either), but you can manually close the connection used by the Sql instance:
Sql sql = Sql.newInstance("jdbc://...")
// some queries
sql.close()
See the JavaDoc.
If you would like to use pooled connections (which is surely a good idea), you should be able to create a pooled BasicDataSource (as Spring bean) and use the Sql(DataSource dataSource) constructor of Sql, rather than newInstance().