asort byJavaSite

index

03/10/2010
03/09/2010
03/08/2010
03/05/2010
03/03/2010
03/02/2010
02/22/2010

sitios en español

03/10/2010
Javalobby
JIRA Studio Now Integrated with Google Apps
mitchp03/10/2010 at 11:00:57
Atlassian currently is in the process of migrating their employees from Zimbra to Google Apps to reflect their recent move to integrate JIRA Studio, their hosed SDL package, with the Google Apps suite.  With the relaunch of the Google Apps Marketplace, JIRA Studio is now available for download on that site as well.  Google Apps are used by over 2 mil
 TOP
Javalobby
Cassandra Usurping MySQL on Twitter
mitchp03/10/2010 at 08:48:03
One source had confirmed that Twitter was working with the NoSQL data store, Cassandra, late last year.  Some more details have finally surfaced about this quiet transition from a MySQL + Memcached system to Cassandra.  The MyNoSQL blog recently interviewed Ryan King, who is leading the Cassandra conversion efforts at Twitter.
 TOP
Javalobby
NOSQL Movement - Excited with the coexistence of Divergent Thoughts
debasishg03/10/2010 at 05:13:18
Today we are witnessing a great bit of excitement with the NoSQL movement. Call it NoSQL (~SQL) or NOSQL (Not Only SQL), the movement has a mission. Not all applications need to store and process data the same way, and the storage should also be architected accordingly. Till today we have always been force-fitting a single hammer to drive every nail. Irrespective of how we process data in...
 TOP
Javalobby
tc Server Spring Edition Improves Visibility and Productivity in the Cloud
jsugrue03/10/2010 at 05:05:57
SpringSource have just announced tcServer Spring Edition, giving develpers and operators better visibility into their Spring applications deployed into cloud environments. tcServer, based on Tomcat is a popular choice for developers who want to take advantage of the Spring supported application server, and with this announcement, it gives a more compelling reason to use tcServer for your...
 TOP
03/09/2010
Javalobby
Developing and Deploying Java on Middleware and in the Cloud: Rise of the Virtual Appliance?
demobox03/09/2010 at 23:25:56
From Java EE to Google App Engine to GigaSpaces, the idea of developing against a middleware or "infrastructure" API is well established in the Java world. James Sugrue
 TOP
Javalobby
Cache Java Webapps with Squid Reverse Proxy
vineetmanohar03/09/2010 at 23:22:10
This article shows you step by step how to cache your entire tomcat web application with Squid reverse Proxy without writing any Java code. James Sugrue
 TOP
Javalobby
Pair Programming: Some Thoughts
markhneedham03/09/2010 at 23:07:56
Mark Wilden pointed me to a post he's written about his experience pair programming at Pivotal Labs where he makes some interesting although not uncommon observations. When you pair program, you're effectively joined at the hip with your pair. You can't pair if only one of you is there. James Sugrue
 TOP
Javalobby
Daily Dose - Simon Phipps' Last Day at Sun
mitchp03/09/2010 at 21:00:32
Simon Phipps' Last Day at Sun  
 TOP
Javalobby
Titanium 1.0 - Native Web Apps Have Arrived
mitchp03/09/2010 at 21:00:09
Today is a major milestone in the evolution of the web as an open development platform.  Appcelerator's newly unveiled Titanium 1.0 framework lets web developers build native applications for the iPhone and Android phones using nothing but web languages.  This means that Titanium applications can leverage any functionality of the iPhone or Android operating systems without going through a...
 TOP
TheServerSide.com
JFrog and Gradle to collaborate on fuller build system offering
Rob Barry03/09/2010 at 12:52:47
Enterprise build system, Gradle Inc. and repository specialist JFrog have formed a collaborative relationship to work toward a series of offerings that the companies say will enhance user productivity. The companies will begin packaging JFrogs repository manager, Artifactory and Gradle together as a more complete build offering.


 TOP
TheServerSide.com
soapUI adds testing support for JMS, AMF and databases
Rob Barry03/09/2010 at 11:30:04
Web services testing software vendor eviware has released soapUI 3.5, which now supports the testing of JMS, AMF and databases. Free and open-source, soapUI is a desktop application used in inspecting, invoking, developing, simulating and testing Web services. The interface is designed to feel like the IDEs that are already familiar to developers.


 TOP
TheServerSide.com
Application Performance: Expert webcasts now available on-demand
Tracie Berardi03/09/2010 at 10:36:59
Did you miss our Application Performance Management virtual seminar in February? In these expert presentations discover the best techniques for perfecting performance builds and for finding, diagnosing and fixing performance bugs. Gain instant access to the latest tools for mastering performance management across the lifecycle.


 TOP
Javalobby
A Look Inside JBoss Microcontainer - The Virtual Deployment Framework
alesj03/09/2010 at 09:26:27
It's been a long time since our JBoss ClassLoading article. During this time we've been quite busy with the new Microcontainer 2.2.x version series, which is already included in the latest JBossAS6_M2.In this article, I am going to talk about our new Virtual Deployment Framework (VDF).
 TOP
TheServerSide.com
5 Article Series on Reloading Java Classes
Jevgeni Kabanov03/09/2010 at 07:24:52
Five articles on classloaders, objects, classes, redeploying, OSGi, Tapestry 5, HotSwap, JRebel and other aspects of Java class reloading and turnaround.


 TOP
TheServerSide.com
Relax: You Can (Mostly) Stop Using Java Interfaces For Testing
Eugene Ciurana03/09/2010 at 07:07:19
Are you tired of turning every non-trivial class into an interface, and then create an "Impl" that actually does the work when mocking objects for testing? Do you know about JMock's ClassImposterizer? It allows you to mock instances without calling the constructor of the mocked class, ultimately helping you write and test your code faster.


 TOP
Javalobby
Frank Wierzbicki on Jython and Switching from Sun to Startup
ehagan03/09/2010 at 06:57:44
Frank Wierzbicki is the Jython project lead and a lead developer at Sauce Labs.  He's been working on Jython as an open source project since 2004 and using Jython since 1999. After a year at Sun, Wierzbicki now works for Sauce Labs, a startup that builds a commercially-supported version of the popular Selenium web app testing system.  Sauce Labs also provides on-demand cloud analytics to run...
 TOP
Javalobby
Ehcache 2.0 Gets More 'Enterprisey' Features
mitchp03/09/2010 at 05:00:09
Today, Terracotta is releasing new versions of Ehcache and the Terracotta infrastructure.  Terracotta's open source products offer enterprise-level capabilities that you might find in a high priced proprietary product like Oracle Coherence.  Today's bundle release, which is appropriately named "Project Darwin", contains Terracotta version 3.2.1, Terracotta Express Web Sessions, and a...
 TOP
Javalobby
VCS Survey
martinfowler03/09/2010 at 04:41:51
When I discussed VersionControlTools I said that it was an unscientific agglomeration of opinion. As I was doing it I realized that I could add some spurious but mesmerizing numbers to my analysis by doing a survey. Google's spreadsheet makes the mechanics of conducting a survey really simple, so I couldn't resist.References Reference:  ...
 TOP
03/08/2010
Javalobby
Design Patterns Uncovered: The Visitor Pattern
jsugrue03/08/2010 at 23:40:22
Today we're going to take a look at the Visitor pattern. Of all of the patterns that I've used so far, Visitor is by far the most powerful and convenient.   Vistors in the Real World A real world analogy always helps with the understanding of a design pattern. One example I have seen for the Visitor pattern in action is a taxi example, where the customer calls orders a taxi, which arrives at...
 TOP
TheServerSide.com
XNIO: A Better NIO For Java
Charles Colt03/08/2010 at 07:21:40
Free your apps from the bugs and headaches of Java NIO. XNIO offers NIO capability but in a hassle-free manner and vastly simplifies the opening of channels with support for SSL and virtual channels within the same API. Learn more about this open source project from JBoss and how to integrate it into your applications.


 TOP
03/05/2010
TheServerSide.com
JSR-310 date and time API early draft review
Stephen Colebourne03/05/2010 at 10:12:15
JSR-310 the Date and Time API inspired by Joda-Time, has entered Early Draft Review. Feedback is wanted!


 TOP
03/03/2010
java.net
Rethinking Multi-Threaded Design Priniciples
dbroy0503/03/2010 at 19:29:32
Designing and improvising a thread based application is a challenge. But by following certain design principles and guidance, this can be easily overcome.
Rethinking Multi-Threaded Design Priniciples
Wed, 2010-03-03
Designing and improvising a thread based application is a challenge. But by following certain design principles and guidance, this can be easily overcome.



Introduction

For many years, we have been using Java Threads for developing numerous Client-Server based applications. While it's always desirable to have a highly responsive Client application, handling a high volume of client requests has always been a prime goal of any Server application. However, designing a highly-scalable server requires lots of analysis. Without careful design and adherence to a well thought out underlying policy, a thread based system can fail to produce the desired outcome.

In this article, we'll discuss certain design principles that should be followed when the objective is to build an efficient, thread-safe application.

Thread Safety lies in Domain

As a design principle of thread safety, the vital point to look into is "Domain First." After all, the whole structure of an application lies on the Domain itself. If you get your domain model right, most of the problems are automatically taken care of. A model represents certain aspects of business logic consisting of various constraints and invariants. Understanding the pre and post conditions of a model are much needed in order to make the realized application thread-safe.

Let's imagine an travel agency that arranges budgeted cars for their traveler guests. They need an interactive car rental application that allows them to book multiple cars at different tourist locations on different dates within a specified price range. As they keep making multiple rental requests, at the same time if the system fails to find a car at particular location within price range, they want to be notified with suggested locations on the same screen.

We can think of this as a booking Requester taking the renal requests and putting them in a thread safe collection CarBookings that would be read concurrently by an actual CarFinder process to provide suggested locations. If CarFinder succeeds, it forwards this via the booking engine to the booking rental location. If CarFinder does not succeed, it tries to find the cars based on the price range and nearest location. Once found, it adds the info to another thread safe collection CarBookingAdvices.

There are many thread safe data structures available, but if you're sure about the Thread Safety policy that you want to adhere to, it's best to create a domain model on your own. For example:


class CarBookings{
    private final Set bookings = new HashSet();

    public synchronized void putCar(CarBooking booking){
        bookings.add(booking);
    }

    public synchronized Set getBookings(){
        return Collections.unmodifiableSet(bookings);
    }
}

Since the methods putCar() and getBookings() provide a secure way of accessing the non-thread-safe instance variable bookings, the CarBookings can be used safely by both the BookingRequester and CarFinder process running in different threads. This meets our simple thread safety requirement.


//Defining BookingAdvice
class BookingAdvice{
    private final String bookingId="";
    private final BigDecimal rate=new BigDecimal("");
    private final String location="";
//Getter and Setter ommited
}

class BookingAdvices{
    private final Set<BookingAdvice> advices = new HashSet<BookingAdvice>();

    public synchronized void putAdvice(BookingAdvice advice){
        advices.add(advice);
    }

    public synchronized Set<BookingAdvice> getAdvices(){
        return Collections.unmodifiableSet(advices);
    }
}

//Defining Requester
class BookingRequester{
    private CarBookings bookings;
    private BookingAdvices advices;

    public void requestBooking(CarBooking booking){
        bookings.putCar(booking);                     //Line 1
        displayAdvice(advices.getAdvices());      //Line 2
    }

    private void displayAdvices(Set<BookingAdvice> advices){
        //Displays the advices on the same screen
    }
}

//Defining Finder
class CarFinder{
    private BookingAdvices advices;
    private CarBookings bookings;

    public void processAdvice(){
        List<BookingAdvice> adviceList = getGeneratedAdvices();
          for(BookingAdvice advice: adviceList)
            advices.putAdvice(advice);                //Line 3

        findAndProcessBookings(bookings.getBookings()); //Line 4
    }

    private List<BookingAdvice> getGeneratedAdvices(){
        //Generate advice based on requests
    }

    private void findAndProcessBookings(Set<CarBooking> bookings){
        //Finds advice for the booking if required
    }
}

Hiding Model State

But, there is a caveat: if the CarBooking class is mutable, then there is a possibility of modifying each CarBooking instance in the set returned by getBookings(). Does it make our model brittle? Well, as long as we can make sure that it won't be modified later on, we'll be fine with that. But, sometimes it's easier get thread safety by hiding the model state and blocking the access to it thereafter. Here, we make CarBooking immutable and add a copy constructor:


class CarBooking{
    private final String bookingId;
    private final String location;
    private final BigDecimal rate;

    //Copy constructor
    public CarBooking(CarBooking booking){
        this.bookingId= booking.getBookingId();
        this.location= booking.getLocation();
        this.rate= booking.getRate();
    }
    //public Getter methods below
}

class CarBookings{
    //Modified version
    public synchronized Set getBookings(){
        Set newBookings = new HashSet();
        for(CarBooking b : bookings){
            CarBooking newBooking = new CarBooking(b);
            newBookings.add(newBooking);
        }
        return Collections.unmodifiableSet(newBookings);
    }
}

So, when getBookings() returns, it returns a copy of the CarBooking, thus not allowing modification of the original state--which makes it purely thread safe.

Do Thread Delegation if you can

Sometimes you might find yourself being overburdened with handling the thread safety in your domain model; in that case you can simply delegate it to a range of Java built-in data structures that are already proven and tested to be thread safe. Like in our example, if we had to use bookings as HashMap<String, CarBooking>, where String could represent bookingId, we could have easily replaced that with ConcurrentHashMap--which is a thread safe HashMap. Likewise there are many other data structures available (under the java.util.concurrent package) like CopyOnWriteArrayList and ConcurrentLinkedQueue, to name a few.

Figuring Single Thread Confinement

To coordinate multiple threads in a lock-based application, the OS and JVM have to burn fair amount of CPU cycles for context switching and thread scheduling--making the system less responsive sometimes.

This can be avoided by allowing only one thread to gain access to work on a unit model (either CarBooking or BookingAdvice) at a time, and also making sure that same unit model should not be re-worked by the same thread. To make this happen, we can employ bounded BlockingQueues (BookingQ and AdviceQ) that would act as a mediator between Requester and CarFinder. So, for a rental request, the Requester would just create a CarBooking and put it in the BookingQ queue, and on the other hand, CarFinder would take that off of the queue. The same thing will be done by the CarFinder to return a BookingAdvice in the AdviceQ queue. This way, multiple Requesters and CarFinders can work asynchronously, making the system highly responsive.

Use synchronized lock wisely

While synchronized lock provides an easy way to work with multiple threads, improper usage of the lock may cause unpredictable results. This becomes obvious when multiple locks are acquired to perform an atomic operation where the first lock is held until last lock operation is performed. Let's consider our BookingRequester and CarFinder that are using simple java Sets instead of CarBookings and BookingAdvices. Here two operations: putting request and getting advices for Requester (vice versa for CarFinder, lines 5,6,7 and 8) become implicitly atomic under the same lock:


class BookingRequester{
    private final Set bookings = new HashSet();
    private final CarFinder finder;

    public BookingRequester(CarFinder cf){
        finder = cf;
    }
    public synchronized void requestBooking(CarBooking booking){
          bookings.add(booking);                    //Line 5

        displayAdvice(finder.getAdvices());    //Line 6
    }

    public synchronized Set getBookings(){
        return bookings;
    }
}
class CarFinder{
    private final Set advices = new HashSet();
    private BookingRequester bookings;

    public CarFinder(BookingRequester br){
        bookings = br;
    }
    public synchronized void processAdvice(){
        List adviceList = getGeneratedAdvices();
          for(Advice advice: adviceList
              advices.add(advice);            //Line 7

        findAndProcessBookings(bookings.getBookings());    //Line 8
    }

    public synchronized Set getAdvices(){
        return advices;
    }

}

Now, a problem starts to creep in when two threads T1 and T2 try to call Requester requestBooking() and CarFinder processAdvice() respectively at the same time. During requestBooking, before T1 calls getAdvices() on CarFinder (Line 6), it has to wait for T2 to complete processAdvice. But to complete processAdvice, T2 needs to call getBookings() on Requester (Line 8), which won't happen until T1 completes requestBooking()--leading to a deadlock situation.

In our previous implementation of BookingRequester and CarFinder, we have already delegated the two operations to be handled independently under different locks (one for CarBookings and another for BookingAdvices, lines 1, 2, 3 and 4) to avoid any deadlock.

But, here we can simply resolve it by moving synchronized from the entire method to only the time required to put the booking (Line 5) and advice (line 7).

Another important point regarding deadlocks would be the order in which the resources are accessed in an atomic operation. If two threads work on an operation with two resource locks being held in a different order, it can lead to a deadlock situation too. So, make sure all threads calling an atomic operation get all resource locks in the same order.

Conclusion

Designing and improvising a thread based application is a challenge. But by following certain design principles and guidance, this can be easily overcome. At the same time, clear understanding of thread safety policy is also essential as it helps you simplify the design. There are many other techniques available that we couldn't cover here. However, the principles presented here will always assist you in overcoming some of the thread safety related hurdles you might be facing as you develop thread-safe applications intended for operation on modern multicore and multiprocessor computers.

Dibyendu Roy has more than ten years of design and development experience in various domains including Banking and Financial Systems, Business Intelligence tools and ERP products.
 TOP
TheServerSide.com
WSO2 debuts SaaS identity management product
Rob Barry03/03/2010 at 08:22:50
Middleware vendor WSO2 recently released Cloud Identity, which the company said eliminates the need for internal software, dedicated hardware, and systems administrators in identity management. Instead, WSO2 provides enterprise identity management as a pay-as-you-go, hosted service that scales.


 TOP
TheServerSide.com
TheServerSide.com redesign in high gear
Bree Matturro03/03/2010 at 07:36:43
TechTarget has been working on a project to redesign TheServerSide.com. Updates to the site will be noticeable in the near future.


 TOP
03/02/2010
TheServerSide.com
Tech Brief: NoSQL for DBAs
Eugene Ciurana03/02/2010 at 22:54:08
NoSQL describes several database technologies for which the data stores don't need a fixed schema and often avoid join operations. Brian Aker gives a lightning talk (7 minutes) about NoSQL during the Nov 2009 OpenSQLCamp in Portland, Oregon.


 TOP
DevX.com
Taking a Java-Based App Offline Using Flash Builder, LiveCycle Data Services
Daniel Morgan03/02/2010 at 14:04:22
This article builds a sample application that can seamlessly transition between online and offline connectivity status.
 TOP
02/22/2010
java.net
Has JDBC Kept up with Enterprise Requirements?
jldavis00702/22/2010 at 19:31:10
Look beyond Type 4 architecture to address the latest requirements of the enterprise Java ecosystem.
Has JDBC Kept up with Enterprise Requirements?
Mon, 2010-02-22
Look beyond Type 4 architecture to address the latest requirements of the enterprise Java ecosystem.



Part of the Java Standard Edition since the release of the Java Development Kit 1.1, the Java Database Connectivity (JDBC) API has become the industry standard for providing standards-based data access from Java. It allows you to have a single API into a database connectivity driver--whether it be Oracle, SQL server, or DB2--and to write your application code in such a way that you needn't concern yourself with the underlying data source.

Evolution of JDBC drivers

The JDBC API specification and the drivers it enables have evolved over time, from the original (Type1) drivers--JDBC-ODBC bridges that are dependent upon ODBC drivers and native database libraries on the client side and that are comparatively lacking in features--to native-protocol (Type 4) drivers, also known as Direct to Database Pure Java Drivers, which are entirely written in Java, are platform-independent, and are run inside the client's Java Virtual Machine (JVM) requiring no associative software (such as libraries) to work. Some type 4 drivers have also come to offer numerous features--single sign-on, Kerberos security, and NTLM authentication, for example--largely addressing the need to securely integrate JDBC drivers with complex application servers and database features targeting the enterprise market.

As much as JDBC driver architecture has evolved, however, evolution within the enterprise Java ecosystem has left it with some troublesome shortcomings. Ironically, one trend that has helped to make Java-based, data-driven applications so pervasive in global IT organizations has also taken JDBC off the radar for many developers, who remain unaware of these shortcomings and/or how to address them. That trend is the movement away from a data access model where Java developers program directly to JDBC to a model where they instead use a framework-based object-relational mapping (ORM) technology--such as JPA, Hibernate, or Spring--or an application server such as JBoss that sits on top of JDBC. With these newer, more accessible data models that permit no access to underlying JDBC calls, developers almost never think about JDBC or what JDBC driver to use as part of determining a data access strategy.

However, the JDBC drivers used in contemporary enterprise application design, deployment, and runtime scenarios are well worth thinking about. As things have stood, evaluating a JDBC driver has meant simply selecting a JDBC driver with the best architecture--that is, a Type 4 JDBC driver. Until very recently, however, JDBC architecture types have remained constant in the face of rapidly changing IT conditions within the enterprise. Aside from the widespread adoption of ORM-based data access models discussed above, some of the more sweeping and significant developments include virtualization, advancements and new features in database technologies, and rapid adoption of business intelligence and data warehousing initiatives:

  • The proliferation of virtualizing both hardware and software resources has made it possible for IT organizations to deliver massive scalability on an affordable growth curve, placing a much higher value than ever before on efficiency and optimum performance throughout the entire application stack.
  • The increasingly more complex features and functionality of relational database offerings, while in high customer demand, frequently involve complicated and proprietary implementations that have made them all but inaccessible to most applications.
  • And enterprise organizations standardizing on a single RDBMS platform as their data warehouse must move vast amounts of data from diverse systems and are discovering that time-consuming data loads using batch mechanisms are impeding the production of timely business intelligence reports.

Limitations of Type 4 JDBC drivers

While superior to other JDBC driver architecture types, most Type 4 drivers come with glaring limitations that make them impractical for today's Java-based enterprise application environments. Most, for instance, require changes in an application's JDBC code in order to be tuned for performance. Doing this for each unique application deployment scenario is unmanageable and impractical. When you throw an ORM on top, if you must have a vendor-specific statement method, you'll be unable to do that casting without modifying the code of the ORM. So unless you want to be modifying, let's say, a Hibernate implementation, you need to make sure that those JDBC drivers are clean--that is, that they adhere to the standard while yet executing things in a flexible manner.

Suppose you've been tasked with tracking down the memory usage of an application you've written with Hibernate. You've traced and tuned, and think you should be able to squeeze more out of your Oracle database drivers. For this specific example, we'll say that we need to tune parameter bindings.

In order to more accurately control the amount of memory the driver allocates for each parameter in the PreparedStatement using Oracle's Thin driver, you must use the OraclePremparedStatement.defineColumnType() method (which is not part of the JDBC specification).

Listing 1.


PreparedStatement pstmt = con.prepareStatement(
   "insert into perftest (id, code, descr, insert_user, insert_date)
   values (?,?,?,?,?)");

((OraclePreparedStatement)pstmt).defineColumnType(1, Types.INTEGER);
((OraclePreparedStatement)pstmt).defineColumnType(2, Types.VARCHAR, 50);
((OraclePreparedStatement)pstmt).defineColumnType(3, Types.VARCHAR, 100);
((OraclePreparedStatement)pstmt).defineColumnType(4, Types.VARCHAR, 100);
((OraclePreparedStatement)pstmt).defineColumnType(5, Types.TIMESTAMP);

pstmt.setInt(1, count);
pstmt.setString(2, Integer.toString(count));
pstmt.setString(3, "123456789012345678901234567890");
pstmt.setString(4, "TONGUC");
pstmt.setDate(5, new java.sql.Date(System.currentTimeMillis()));
pstmt.execute();

However, if on a subsequent execute you should re-bind your parameters using larger data sizes, then the driver will be silently truncated to the size specified--not a good thing. Also, due to the fact that Hibernate abstracts the actual JDBC calls themselves, you lose the power to customize these calls unless you modify the Hibernate code itself, thus casting the PreparedStatement to an OraclePreparedStatement in the process. This is generally unacceptable, as it is costly to modify the Hibernate code and you must duplicate the code changes every time you upgrade the version of Hibernate you're using.

A much less costly option would be to tune memory at the JDBC driver level, where connect options could be specified to set the initial size to be tried for each parameter. This simple solution would save you from having to change Hibernate code in order to tune the application, and could also--by having the driver auto-adjust for the parameter's size--remove the limitation of truncating the data on subsequent executes and binds, making it unnecessary for you to spend time analyzing every parameter binding.

One of the promises on which the typical Type 4 driver architecture has failed to deliver is simple and uncomplicated deployment. It is anything but. Multiple JAR files are required to support deployment across different JVMs or hardware, as well as to access all supported versions of a particular database. This limitation can be overcome by packaging the JDBC driver as a single JAR file regardless of the IT environment, having no dependencies on external DLLs or shared libraries or native database components outside the JVM.

Listing 2. Code sample illustrating all-in-one (clean) implementation.


con = DriverManager.getConnection("jdbc:datadirect:oracle://nc-pgm1;
    databaseName=orcl; user=scott; password=tiger;
    initialColumnBufferSize=128");
PreparedStatement pstmt = con.prepareStatement(
    "insert into perftest (id, code, descr, insert_user, insert_date)
    values (?,?,?,?,?)");
pstmt.setInt(1, count);
pstmt.setString(2, Integer.toString(count));
pstmt.setString(3, "123456789012345678901234567890");
pstmt.setString(4, "TONGUC");
pstmt.setDate(5, new java.sql.Date(System.currentTimeMillis()));
pstmt.execute();

The support of typical Type 4 drivers for mission-critical database features targeting the enterprise is nearly always limited to a bare minimum of functionality. Many such features require proprietary code and the use of external DLLs or shared libraries--security features, bulk data loading, high availability, and XA features ordinarily do, for instance. With each data source that an application must support, the amount of data-source-specific code that must be maintained increases. In most cases, the driver simply exposes whatever support for these features is implemented by the database layer. Consequences of this strategy include inefficiency due to performance overhead, use of proprietary code, and requirements to license expensive database clustering technologies. These can be addressed with 100 percent JDBC-compliant driver-layer-only implementations.

Bulk load and JDBC drivers

Bulk load, a type of feature that addresses the limitations of batch data loads mentioned earlier, deserves a closer look in this context--not least because it has real potential to be a truly game-changing concept for organizations implementing or planning to implement data warehousing for reporting, decision support, and data mining purposes--in other words, just about any enterprise-scale business organization today.

Traditionally, moving very large amounts of data required the use of something called a bulk-moving tool or bulk-loading tool. An example would be a SQL loader, or a Sybase SQL Server BCP, or the DB2 Load command. Available for decades, these are tools that people use and build within their infrastructure on the back end. The demand for data in the enterprise makes such tools necessary; however, in light of the trend to standardize data on a single warehouse platform, the challenge becomes whether or not these tools can be used in a standard way. You've got SQL loader and BCP and DB2 Load, and they're all different. To this point, the only way to do this in any API has been through a batch mechanism such as JDBC batches. But batch methods are prohibitively slow for most data warehousing initiatives.

With JDBC driver technology that communicates directly in the native "wire" protocols of target databases, bulk load technology that's long been locked in C code can be applied to Java for bulk loading even non-relational data from a mainframe platform into a relational data warehouse. Say you have a key application in your organization that stores its data in a VSAM file on the mainframe. But all your BI dashboards and reporting analysis run against Oracle. How do you unlock that crucial data and make it available to your analysis staff so they can operate on the data using their accustomed tools?

You might deploy an event-driven scenario to trigger a bulk load into Oracle from the VSAM file whenever a given set of conditions is met. It would perform a single Select statement from the VSAM file, pass the ResultSet to the load method on a bulk load object for the Oracle database, and insert the data. If you imagine that it would take an awful lot of coding to accomplish this, you'd be mistaken. This graphic gives a real-life example of the code used to implement one such scenario.


Figure 1. A look at the code

In this example, a mere five lines of code were used to pull data out of VSAM and bulk load it into an Oracle database!

Conclusion

JDBC Type 4 drivers offer the best architecture and are adequate for many data-driven Java-based applications and scenarios. Nevertheless, the numerous solutions required to address serious shortcomings within demanding, complex, and sophisticated enterprise environments warrant looking beyond what a bare-bones Type 4 architecture typically offers--that is, client-side, single-tier, 100 percent Java architecture. A JDBC driver thus designed but that also embraces a comprehensive suite of such solutions might even, perhaps, be better thought of as a "Type 5" JDBC driver. To sum up what a "Type 5" driver should offer:

  • Unrestricted performance: Data throughput is maximized regardless of the runtime environment or data access model.
  • Codeless enhancement: Features and functionality can be added, configured, or tuned for any application without changing application code, regardless of runtime or data access model.
  • Resource efficiency: Use of application runtime CPU and memory resources is minimized and can be tuned as needed to fit specific runtime environment parameters or limits.
  • All-in-one deployment: A single driver JAR file that maximizes the data access simplicity for any Java environment or application.
  • Streamlined standard: No proprietary extensions to the JDBC specification are required for any supported data source--a "clean" spec implementation.

Such "Type 5" JDBC drivers would truly enable modern data-driven Java applications to take advantage of years of innovation in database features, data access models, and virtualization technologies--in many cases without requiring code changes. This in turn would save organizations considerable time and money enhancing their modern data-driven Java applications by expanding feature sets and improving performance and reliability without having to make major changes to those applications.

Jesse Davis is a Senior Program Manager at Progress|DataDirect, responsible for product development initiatives and forward looking research. Jesse is an active member of the JDBC Expert Group, working on the next version of JDBC.
AttachmentSize
Graphic1.png13.04 KB
 TOP
onJava.com
jQuery: Novice to Ninja
Earl Castledine02/22/2010 at 13:31:32

jQuery: Novice to Ninja is a compilation of best-practice jQuery solutions to meet the most challenging JavaScript problems. In this question-and-answer book on jQuery, you'll find a cookbook of ready-to-go solutions to help breathe life into your web page. All code used to create each solution is available for download and guaranteed to be simple, efficient and cross-browser compatible.

 TOP

 

 

JAVAsight.comcontactUS

 
 

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. javasight is independent of Sun Microsystems, Inc.