<?xml version="1.0" encoding="UTF-8"?><rss version="0.92">
<channel>
	<title>bit Java dot com</title>
	<link>http://www.bitjava.com</link>
	<description>Java Developer's Toolkit</description>
	<lastBuildDate>Tue, 13 Jul 2010 14:10:37 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	<!-- generator="WordPress/3.0.1" -->

	<item>
		<title>What Is a java.lang.OutOfMemoryError?</title>
		<description><![CDATA[A java.lang.OutOfMemoryError is a subclass of java.lang.VirtualMachineError that is thrown when the Java Virtual Machine is broken or has run out of resources that are necessary to continue the operation of the Java Virtual Machine. Obviously, memory is the exhausted resource for a java.lang.OutOfMemoryError, which is thrown when the Java Virtual Machine cannot allocate an object due to memory constraints. Unfortunately, the Java specification of java.lang.OutOfMemoryError does not elaborate further on what kind of memory it&#8217;s talking about. There are six different types of runtime data areas, or memory areas, in the Java Virtual Machine (see Figure 1). Program Counter Register Java Virtual Machine Stack Heap Method Area Runtime Constant Pool Native Method Stack The Program Counter Register, also known as the pc register, stores the address of the Java byte code instruction that is currently being executed (just like the processor register in your central processing unit of the device from which you are reading or printing this article). You will not see a java.lang.OutOfMemoryError from the pc register since a program counter is not conventionally considered as a memory. Java Virtual Machine Stacks contain frames where data, return values, and partial execution results are stored. Java Virtual Machine Stacks [...]]]></description>
		<link>http://www.bitjava.com/?p=93</link>
			</item>
	<item>
		<title>Type 4 &#8211; the Native-Protocol Driver</title>
		<description><![CDATA[The JDBC type 4 driver, also known as the native-protocol driver is a database driver implementation that converts JDBC calls directly into the vendor-specific database protocol. The type 4 driver is written completely in Java and is hence platform independent. It is installed inside the Java Virtual Machine of the client. It provides better performance over the type 1 and 2 drivers as it does not have the overhead of conversion of calls into ODBC or database API calls. Unlike the type 1 and 2 drivers, it does not need associated software to work. A native-protocol fully Java technology-enabled driver converts JDBC technology calls into the network protocol used by DBMSs directly. This allows a direct call from the client machine to the DBMS server and is a practical solution for Intranet access. Since many of these protocols are proprietary the database vendors themselves will be the primary source for this style of driver. Several database vendors have these in progress. As the database protocol is vendor-specific, separate drivers, usually vendor-supplied, need to be used to connect to the database. A Type 4 driver uses Java to implement a DBMS vendor networking protocol. Since the protocols are usually proprietary, DBMS [...]]]></description>
		<link>http://www.bitjava.com/?p=88</link>
			</item>
	<item>
		<title>Type 3 driver &#8211; the Network-Protocol Driver</title>
		<description><![CDATA[The JDBC type 3 driver, also known as the network-protocol driver is a database driver implementation which makes use of a middle-tier between the calling program and the database. The middle-tier (application server) converts JDBC calls directly or indirectly into the vendor-specific database protocol. This differs from the type 4 driver in that the protocol conversion logic resides not at the client, but in the middle-tier. However, like type 4 drivers, the type 3 driver is written entirely in Java. The same driver can be used for multiple databases. It depends on the number of databases the middleware has been configured to support. The type 3 driver is platform-independent as the platform-related differences are taken care by the middleware. Also, making use of the middleware provides additional advantages of security and firewall access. A net-protocol fully Java technology-enabled driver translates JDBC API calls into a DBMS-independent net protocol which is then translated to a DBMS protocol by a server. This net server middleware is able to connect all of its Java technology-based clients to many different databases. The specific protocol used depends on the vendor. In general, this is the most flexible JDBC API alternative. It is likely that all [...]]]></description>
		<link>http://www.bitjava.com/?p=84</link>
			</item>
	<item>
		<title>Type 2 Driver &#8211; the Native-API Driver</title>
		<description><![CDATA[The JDBC type 2 driver, also known as the Native-API driver is a database driver implementation that uses the client-side libraries of the database. The driver converts JDBC method calls into native calls of the database API. The type 2 driver is not written entirely in Java as it interfaces with non-Java code that makes the final database calls. The driver is compiled for use with the particular operating system. For platform interoperability, the Type 4 driver, being a full-Java implementation, is preferred over this driver. A native-API partly Java technology-enabled driver converts JDBC calls into calls on the client API for Oracle, Sybase, Informix, DB2, or other DBMS. Note that, like the bridge driver, this style of driver requires that some binary code be loaded on each client machine. However the type 2 driver provides more functionality and performance than the type 1 driver as it does not have the overhead of the additional ODBC function calls. Type 2 drivers use a native API to communicate with a database system. Java native methods are used to invoke the API functions that perform database operations. Type 2 drivers are generally faster than Type 1 drivers. Type 2 drivers need native [...]]]></description>
		<link>http://www.bitjava.com/?p=82</link>
			</item>
	<item>
		<title>Type 1 Driver- the JDBC-ODBC bridge</title>
		<description><![CDATA[The JDBC type 1 driver, also known as the JDBC-ODBC bridge is a database driver implementation that employs the ODBC driver to connect to the database. The driver converts JDBC method calls into ODBC function calls. The bridge is usually used when there is no pure-Java driver available for a particular database. The driver is implemented in the sun.jdbc.odbc.JdbcOdbcDriver class and comes with the Java 2 SDK, Standard Edition. The driver is platform-dependent as it makes use of ODBC which in turn depends on native libraries of the operating system. Also, using this driver has got other dependencies such as ODBC must be installed on the computer having the driver and the database which is being connected to must support an ODBC driver. Hence the use of this driver is discouraged if the alternative of a pure-Java driver is available. Type 1 is the simplest of all but platform specific i.e only to Microsoft platform. A JDBC-ODBC bridge provides JDBC API access via one or more ODBC drivers. Note that some ODBC native code and in many  cases native database client code must be loaded on each client machine that uses this type of driver. Hence, this kind of  driver [...]]]></description>
		<link>http://www.bitjava.com/?p=80</link>
			</item>
</channel>
</rss>
