Rob, Your assertions are spot on. As part of my thesis, I need to show the difference in performance between using JDBC and my MINA based drivers. Writing a JDBC driver makes it easy to conduct these tests. That's the primary motivation for the ADBCJ/JDBC driver. The JDBC wrapper is also a 'bridge' technology as you suggested in 3).
One of the features I'm currently working on is a connection pool. This connection pool can function as a traditional connection pool and it can also be used to to multiplex multiple SQL requests over multiple database connections using a single DbSession instance. (If a transaction has been started, it issues each request over a single connection.) I'm still in the process of coding this so I don't have any metrics that show whether or not there's a benefit to multiplexing requests. Granted, you could multiplex multiple requests over multiple connections manually using a thread pool but the ADBCJ API simplifies that. In my tests so far, I'm showing a significant performance increase when using my MINA based drivers. The biggest reason for this is that with my MINA based drivers, I can pipeline multiple requests to the database. I have a test where I execute 1,000 SELECT statements that is 2-3 times faster than JDBC (with or without a thread pool). These results are consistently faster for both MySQL and Postgresql going over the loopback interface. I expect this performance increase to be much more significant when accessing a remote database over the network. -Mike Rob Butler wrote: > What is the benefit of having an 'asynchronous DB driver' when the > asynchronicity is simulated by use of a thread pool over simply > having worker threads for your application logic and using a > synchronous DB driver? In the end, either way you are using a thread > pool. > > The only potential benefits I can think of are: > > 1) Your thread pool could be smaller if your application spends very > little time performing DB work and your application logic takes the > majority of your processing time. But, here again, having a thread > pool for your application logic would probably be a 'Good Thing' so > you can take advantage of multiple cores for your application logic. > > 2) You have implemented an application that supports multiple data > sources (i.e. you can point them to different data sources, not > multiple sources at the same time). Some of those data sources are > truly asynchronous and thus your application is built expecting any > data source to be asynchronous. An asynchronous JDBC wrapper would > allow your application to work unmodified with an SQL DB. But, how > many applications are built with this expectation and support > multiple data sources? It's probably better to build your > application to use worker threads and expect to block during data > access. > > 3) This is a 'bridge' technology until actual asynchronous DB drivers > can be implemented for the various DB's. Some sort of 'standardized' > call-back API would also have to be implemented and accepted in the > industry. > > Are there other benefits I haven't thought of? Or are my assertions > for #1 & #2 above incorrect? > > Thanks Rob > > ----- Original Message ---- From: 이희승 (Trustin Lee) > <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, March 11, > 2008 10:50:15 PM Subject: Re: [OT] Asynchronous database drivers > > I think this is a great idea considering every bottleneck we find out > eventually is often a backend such as database. I'd like to ping my > colleagues who are trying to store web documents into MySQL > database. > > Cheers, > > 2008-02-04 (월), 12:12 -0700, Mike Heath 쓰시길: >> This past weekend I made a release of the asynchronous database >> driver project I've been working on for the past few months. I've >> been working on this project as part of my master's thesis. >> >> I call the project Asynchronous Database Connectivity in Java >> (ADBCJ), http://adbcj.org/. I've implemented asynchronous MySQL >> and Postgresql drivers using MINA. I've also implemented a driver >> that wraps JDBC and achieves asynchronism using a thread pool. The >> API and drivers are still a bit immature and incomplete but I >> thought that making this project more public would help with >> getting some feedback before I get too far. >> >> I have a simple tutorial for using ADBCJ at >> http://code.google.com/p/adbcj/wiki/Tutorial. >> >> Once I'm close to finishing my thesis, I would like to move ADBCJ >> over to Apache and get these drivers production ready but that's a >> ways down the road. >> >> >> -Mike
