In this podcast Rob Steward explains the advantages of using wire protocol drivers. This podcast is runs for 2:56.
You may listen to the podcast here: http://blogs.datadirect.com/media/RobSteward_WireProtocolDatabaseDrivers.mp3
So when we talk specifically about wire protocol architecture drivers, this is something where really what you're talking about is a type 4 JDBC or a completely managed, 100% managed ADO.NET data provider, or in the case of ODBC, you have an ODBC driver which talks directly, opens up a TCP/IP socket or some network socket to the database and directly communicates using the network protocol and using the packets that the databases themselves understand. So that's kind of the difference between a wire protocol and a non-wire protocol, so you may have pretty much any type 4 JDBC driver is going to be talking a wire protocol to the database, because it has to stay within the DM and it can't call any native OS. A type 2 JDBC driver or a partially managed ADO.NET or what most people typically think of as ODBC, you've got that driver component on top of some other native component, and it's that native component that talks across the wire to the database, and the driver itself does not talk directly. So there's a lot of differences, a lot of different architectures out there with which to build the driver.
Now, of course, the obvious question is which one is best, and certainly, in my opinion, the best ones are the wire protocol drivers and the type 4 JDBC because in terms of performance, scalability, functionality, those are always going to be better in terms of performance and scalability in particular, and reliability, as well. When you get into pure Java solutions within the Java environment or 100% managed within .NET, theoretically you can't have things like buffer overruns or memory leaks, so reliability is increased with those type 4 wire protocol type solutions, as well. So -- and also in terms of performance and scalability, the fact that it is a wire protocol, let's say wire protocol ODBC, where that driver talks directly to the database and not through some intermediate component, it's going to perform better because it's designed to do exactly what your ODBC application needs. It doesn't have all this other stuff. It doesn't have double sets of buffering, one in that client layer, one in the driver layer, and the reliability, again, is going to be increased. So, you know, in my opinion certainly type 4 JDBC, 100% managed in the .NET world, and wire protocol ODBC are somewhat equivalent when you think about architecture, and those, to me, would always be the best performing and best scaling solutions.
View all posts from Rob Steward on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
You have the right to request deletion of your Personal Information at any time.
You can also ask us not to pass your Personal Information to third parties here: Do Not Sell My Info
Copyright © 2020 Progress Software Corporation and/or its subsidiaries or affiliates.All Rights Reserved.
Progress, Telerik, Ipswitch, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.