Discussions

News: 5 things you didn't know about Java Database Connectivity

  1. JDBC, or Java Database Connectivity, is one of the most frequently used packages in the entire JDK, and yet few Java developers use it to its fullest — or most up-to-date — capacity. This article offers an introduction to newer JDBC features like ResultSets that automatically scroll and update on the fly, Rowsets that can work with or without an open database connection, and batch updates that can execute multiple SQL statements in one fast trip around the network.

    Threaded Messages (7)

  2. I'm starting to resent the titles of these.  In the last three segments I've read, I've known 13 out of 15 of the "things I didn't know."

    They're really not that profound.  Some of the "newer JDBC features" that Neward refers to were introduced in JDK 1.2 (December 1998!)  Personally, I never used JDBC seriously before JDK 1.2.

    I'm sad because I enjoy watching recordings of Ted Neward speaking, but these articles lower my regard for him.

  3. 5 things you shouldn't care about[ Go to top ]

    OK, this is bit picky but count() isn't a scalar function.  Bad start.  Is anyone really still trying to implement RDBMS neutral SQL?  Trying to avoid using the vendors functions is usually a waste of time (IMO).

    Scrollable ResultSets: avoid.  Stick with forward only.  This seems great until you realize how inefficient it is from the RDBMS side and all the cursor isolation complications you have to contend with.   In my last decade of database software development, I've needed to use bidirectional scolling exactly zero times.

    Updateable resultsets.  Some value here but again you have to contend with isolation issues.  I'm not convinced it's worth the hassle.

    Rowsets: Key words are "Rowset implementations are generally provided by the JDBC driver".  I'll Pass.  Oracle can't even implement the basic JDBC spec properly.  And the article implies it caches the results in memory.

    Batch updates.  First of all, you need to turn autocommit off?  If you are using autocommit, this article is way over your head.  Anyway, batch updating is vendor specific and has a lot of pitfalls.  If you need it I guess you have to use it.  It should be a last resort, though.

  4. 5 things you shouldn't care about[ Go to top ]

    Also, there's (driver specific?) limits to how much to can addBatch. Eventually it will get sick and die if you use too much (at least it did with Oracle back in the day, I haven't used addBatch in a long time). We ended up wrapping in an outer layer that would ship off the current batch when we hit about 64K of SQL so as to notannoy Oracle.

    But I agree with the others, at least in the Enterprise world, static, one way cursors are the way to go. For interactive, GUI apps, the other bits may well be useful and handy.

     

  5. 5 things you shouldn't care about[ Go to top ]

    But I agree with the others, at least in the Enterprise world, static, one way cursors are the way to go. For interactive, GUI apps, the other bits may well be useful and handy.

    I would actually say for interactive gui apps (which is what I cut my teeth on) that bi-directional cursors are an even worse idea.  Only if you know there will only be a handful of users would it be workable.  At least on a n-tier architecture, you have some control over the number of database connections and you might even be able to coordinate their activities.  On a client-server app, you have to worry about things like a user starting to scroll and then leaving to go to lunch or a meeting or on vacation.

    Cursors are stateful.  The less you depend on them the better off you are.

  6. At my company we went from the mess that is ORM/Hiberate to using a Versant OB DB. And have never looked back. Life is much simpler now, and the productivity gains are ten fold over anything ORM or JDBC

     

     

  7. At my company we went from the mess that is ORM/Hiberate to using a Versant OB DB. And have never looked back. Life is much simpler now, and the productivity gains are ten fold over anything ORM or JDBC

     

    I agree partially , I never see ORM/Hibernate working completely for any good size reasonable project. I always see people have to add the JDBC code here and there to do many manadotry tasks (batches, blobs that are still very platform specifics etc) related to any reasonable size project. But I am not sure you can live with out JDBC and relation stuff even you go to OO DB. And if I am not mistaken (since I never used any of these OO DB products), all OO DB vendors provide some kind of JDBC/Relation Data base API around their products.

  8. [ Go to top ]

    Big deal, most of that stuff is not very useful, they are just toys.

    Where is the real innovation, like XML type support, POJO load/save, Iterable support, live schema/function sensitive SQL builders, SQL for POJOS and Collections, and memory based data sets with SQL query support?

    They don't exist in the JDK, so I have to search 1000's of libraries on FreshMeat, which takes a lot longer than viewing the JDK Javadocs.